I can't make sense of lots of this.<p>- Without self-replicating grey goo, infinite scalability is surely more a property of some kind of networked computer rental business (like AWS) rather than a database.<p>- What does 'serverless' mean exactly? My understanding is that it denotes a stateless application which is executed to serve a request but doesn't run continually as a daemon. Essentially the aforementioned computer rental business provides the event loop and the program provides the event handler. I fail to see how this is compatible with a database, which is definitionally <i>very</i> stateful. (And that encompasses much, <i>much</i> more than just the data.)<p>- 'Intelligence': Databases already <i>are</i> intelligent and self-optimising, and have been at least since MySQL/Postgres: <a href="https://dev.mysql.com/doc/refman/8.0/en/cost-model.html#cost-model-operation" rel="nofollow">https://dev.mysql.com/doc/refman/8.0/en/cost-model.html#cost...</a><p>- 'Fundamentally reliable': This idea could reasonably be described as, uh, 'not novel'.<p>- 'Distributed globally, locally available': As far as I can tell, this collection of words is entirely devoid of any meaning. It sounds like it came out of a random passphrase generator.<p>- 'Scale should not come at the cost of performance'. While technically semantically meaningful, this is not novel or interesting, and I'm pretty sure this has been a pleasant daydream for database designers since databases were stored in punchcards. As far as I can see, this is comparable to saying 'houses should not come at the cost of money'.<p>This feels more like a laundry list of daydreams rather than a meaningful narrowing-down of how future databases will be architected. "It should be infinitely scalable, usable by a toaster, and it shouldn't need a computer to live on. It should be serverless and stateless but also self-optimising and with connection pooling. It should be consistent, available, and, uh, partitions, it should be cool with those too. It should be usable by anyone and perfectly tailored to their needs as well as to the opposite needs. Also..."
What I struggle with is that half the databases that have been built over the last decade would have claimed these same principles. It isn't so much that these principles are not novel or unique that gives me pause, but the lack of acknowledgement of how many expertly designed databases failed to deliver on them. These principles contain no insights into why anyone should expect this particular database to succeed where similarly qualified people have failed. At a minimum, these principles smuggle in the assumption that several Hard Problems, both theoretical and practical, have been addressed (which is possible but not in evidence).<p>As another way of framing it, these principles seem to be making the unstated assumption that the Future Database only supports a narrow set of data models and workloads. Which would be considerably less interesting than actually reimagining core database architecture and solving hard problems.
If you're truly forward-thinking you'd start planning for multiplanetary databases. Get a leg up on the competition by the time humans reach Mars.<p>The core issues of planetary database systems have mostly been solved already. What about database systems which have to deal with time dilation due to running on spacecraft that travel through space at different velocities?<p>But in all seriousness, one of the core features missing in modern database systems is a way to smoothly handle tracking and deploying changes. Why are online schema changes so difficult?
The biggest missing piece for future databases is the ability to guarantee you only store your data in Europe. All of these databases are coming from the US, with no self-hosting option, or EU region for their SaaS service. With Schrems II it the EU region should be operated by an European company detached from the US company.
Great list. As I can add anything here, I will say:<p>- Bitemporal support OOTB (storage would be more expensive, as temporal data needs more disk space)<p>- CoW capabilities OOTB, so it would be super easy (fast and cheap) to create ephemeral database for development purpose.<p>- Charge per request (ms of reads, ms of writes) - for the sake of being more specific about serverless.<p>- AI capabilities that detects the use of the database and suggests indexes or other tweaks to make the database as fast as possible (and cheap), even if schema changes, database size increases or query patterns change<p>- PostgreSQL support (and all its extensions... I know that's a hard one as PS is based on MySQL)<p>- OOTB capabilities for Masking and/or anonymizing of data (PCI, PII, etc)<p>Thanks
bunch of principles here are specific to using managed 3rd-party database, rather than self host // on-prem<p>meanwhile.. lots of apocalyptic posts lately about how vc funding will dry up since public tech stocks have crashed<p>so how safe is it to have your business completely rely on a managed database startup, instead of self host or using a major cloud provider's direct offering? may be unwise these days methinks