Serverless SQL Database

Hi there,

1. Most likely, right now I use event-sourcing to build aggregates which use whichever model best fits what I'll be doing with the aggregate: sometimes a simple key-value store, sometimes a graph, and sometimes an SQL database. In my opinion there isn't really any "real" serverless offering like you describe, only half solutions like Aurora Serverless.

2. That's a tricky question, as computing the cost is likely quite involved: full scan vs hit, joins, data vs index storage, triggers, etc.; I think the only useful answer I can provide right now is "a cost that scales with my usage" (with a small free tier to be able to test-drive the solution).

3. I'd likely want it to at least be standard SQL compatible, to have the ability to use existing libraries to access the database. In terms of queries, basic things like CRUD operations are a given, inner/left joins. Having JSON and geo operations would be nice but probably not a deal breaker if absent. No triggers or stored procedures. I wouldn't have a use for them (since I'm kind of building views) but views and sequences/auto increments would probably be needed by a lot of applications.

4. Thankfully no (but I expect to be in the minority here)

5. This is all asynchronous and eventual consistency so no strong requirements in terms of consistency/isolation (can read uncommitted, no lock)

Bonus (I feel like typing today):

I honestly expected what you summarized to have been available for a while now. It would be interesting to dig into why this is not the case, I figure the folks at AWS/Azure/GCP have the manpower and skills to at least give it a shot.

I wouldn't be surprised if there was a split right now between:

• on one side people who are used to serverless and go with serverless or at least nosql databases
• on the other side more "old school" - poor wording on my part, not being negative at all - who are now on the container path

Maybe your solution could fit both: serverless people would finally have a real serverless SQL database, and container people would have a way to solve the maintenance/storage aspect of their database instance containers, as it is far trickier than stateless applications.

Either way, if you give this a shot, I'd love to hear about it when it becomes available :-)

I don't quite understand what you mean by Serverless SQL Database? And how does this service-free database differ from a regular database? Where will such a database store all its data, on a separate hosting or in cloud storage? Sorry if I ask too many questions, I'm just not familiar with the term Serverless Database. I hope you can explain in more detail what kind of database it is and why it is called Serverless. Although I am still a novice web developer, but I have already become quite familiar with the creation and interaction with databases. Most often I work in the sql ide, although I also work in MySQL.

If I were to ask,

• how quickly will you want the resources to respond for scaling operation?
  -would apart from autoscaling, what will be your selection criteria?

1- Yes. Do you mean like SQLite? Or is it like Athena, but for application databases?
2- Pay-per-use. Be it queries or data.
3- SELECT, for sure. INSERT too. UPDATE is another one that I'd put at a must status, DELETE is not really necessary as you can use soft deletion - changing a flag from false to true
4- Not really. I used MongoDB for many years before it introduced its multi-document transactions. It is not a problem, but it certainly is a niche.
5- ACID compliance at least on the document level. I don't want to lose the data I insert.

1. Unless there is something unique to your offering (like no hourly charge), I would stick to the standard cloud offerings, as they are more predictable. Any cloud has a database as a service where they manage redundancy, logs, availability, etc. It is pricey especially for pet projects, so the price can lure me in to try something else.
2. The expected price is per hour, but I would be definitely interested in "per storage/per read" like Firestore.
3. All of the queries plus extensions. E.g. like btree_gist, enum.
4. Yes, I usually have a couple of use cases for transactions even in simple MVPs
5. Hard to say as this is very dependent on a project. I think default value for db should be fine for small projects and flexibility will be appreciated.

PS have you seen http://postgrest.org/en/v7.0.0/ ? This model can be very attractive for startups.

This is a tough question.

1. For a toy app or experiment, YES. For a serious or revenue generating app, unlikely.

2. probably per storage and memory.

3. All CRUD operations would be required.

4. Sometimes, yes.

5. Default is usually fine.

For many apps I've built backed by postgres, once I hit some level of scale, it usually requires optimizing the configuration and flags to some degree. Settings like max workers, working memory, or even vacuum thresholds. This is largely driven by workload specific to the app. I'd have some reservations that the system was properly configured or could perform optimally during bursts or scale without knowing how this system is configured, or being unable to change them. However, for fun/sandboxed projects, I think this would be useful.