<story><title>Show HN: WunderBase – Serverless OSS database on top of SQLite, Firecracker</title><url>https://wundergraph.com/blog/wunderbase_serverless_graphql_database_on_top_of_sqlite_firecracker_and_prisma</url></story><parent_chain><item><author>gregwebs</author><text>This just runs a request proxy that turns off after 10 seconds of no activity and starts it up (with a half second delay) when there is a new request. It runs SQLite with Prisma. Prisma is an API server that puts a GraphQL API in front of a DB.&lt;p&gt;It&amp;#x27;s a nice blog post about gluing technology and I can see how this could be a really nice way to run some lower-cost databases in a non-demanding development environment. However, it is not a reliable way of operating a database. For me it isn&amp;#x27;t really serverless since it only scales between 0 and 1 instance whereas a serverless DB ideally would scale-out but should at least have some ability to scale to greater load in response to demand, along with higher reliability and availability, and backing up data to object storage.</text></item></parent_chain><comment><author>nikolasburk</author><text>Hey there, I&amp;#x27;m Nikolas from the Prisma team. Just came here to quickly clarify this notion:&lt;p&gt;&amp;gt; Prisma is an API server that puts a GraphQL API in front of a DB.&lt;p&gt;Prisma is an ORM which generates a JavaScript&amp;#x2F;TypeScript client library for your database.&lt;p&gt;Your description is very true for Prisma 1 (which has been in maintenance mode for several years and is officially deprecated by now [1]), but the latest version(s) of Prisma (v2+) don&amp;#x27;t expose a GraphQL API any more. Prisma 1 also used GraphQL SDL for data modeling, the Prisma ORM on the other hand has its own, custom modeling language for describing database schemas in a declarative way and also comes with a flexible migration system.&lt;p&gt;That being said (and as Jens also mentioned elsewhere), the Prisma ORM does use GraphQL _internally_ as a wire protocol. However, as a developer, you _never_ touch this internal GraphQL layer and are not even supposed to be aware of it (you actually have to jump through a lot of hoops to even &amp;quot;find&amp;quot; it). It&amp;#x27;s also very likely that we&amp;#x27;ll replace GraphQL as a wire protocol in the future, so &amp;quot;GraphQL&amp;quot; really isn&amp;#x27;t something you should be thinking about as a developer who is using Prisma.&lt;p&gt;Hope that clarifies the situation a bit, let me know if you have any further questions around this topic.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;prisma&amp;#x2F;prisma1&amp;#x2F;issues&amp;#x2F;5208&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;prisma&amp;#x2F;prisma1&amp;#x2F;issues&amp;#x2F;5208&lt;/a&gt;</text></comment>
<story><title>Show HN: WunderBase – Serverless OSS database on top of SQLite, Firecracker</title><url>https://wundergraph.com/blog/wunderbase_serverless_graphql_database_on_top_of_sqlite_firecracker_and_prisma</url></story><parent_chain><item><author>gregwebs</author><text>This just runs a request proxy that turns off after 10 seconds of no activity and starts it up (with a half second delay) when there is a new request. It runs SQLite with Prisma. Prisma is an API server that puts a GraphQL API in front of a DB.&lt;p&gt;It&amp;#x27;s a nice blog post about gluing technology and I can see how this could be a really nice way to run some lower-cost databases in a non-demanding development environment. However, it is not a reliable way of operating a database. For me it isn&amp;#x27;t really serverless since it only scales between 0 and 1 instance whereas a serverless DB ideally would scale-out but should at least have some ability to scale to greater load in response to demand, along with higher reliability and availability, and backing up data to object storage.</text></item></parent_chain><comment><author>tptacek</author><text>You can, of course, scale to &amp;gt;1 with the Fly Machines API. I don&amp;#x27;t know enough about how they&amp;#x27;re managing the SQLite part of this to say more about how this scales, except that I think scaling out SQLite is about to get a lot more interesting.&lt;p&gt;But I mostly agree that we need a better term than &amp;quot;serverless&amp;quot; for this kind of stuff. The big things people seem to want from &amp;quot;serverless&amp;quot; solutions are &amp;quot;not managing long-running server instances&amp;quot; and &amp;quot;true usage-metered billing&amp;quot;.&lt;p&gt;Whether or not there are servers, like, at all has not all that much to do with things.</text></comment>