The Future Database
principles.planetscale.com
The Future Database
1–10 of 40 posts
Re: The Future Database
#2My dream was having a database like AWS DynamoDB, but with analytical capabilities built-in the API.
Re: The Future Database
#3The 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.
Re: The Future Database
#4The 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.
Doesn't Upstash allow this?
Re: The Future Database
#5bunch of principles here are specific to using managed 3rd-party database, rather than self host // on-prem
meanwhile.. lots of apocalyptic posts lately about how vc funding will dry up since public tech stocks have crashed
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
Re: The Future Database
#6I can't make sense of lots of this.
- 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.
- 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 very stateful. (And that encompasses much, much more than just the data.)
- 'Intelligence': Databases already are intelligent and self-optimising, and have been at least since MySQL/Postgres: https://dev.mysql.com/doc/refman/8.0/en/cost-model.html#cost...
- 'Fundamentally reliable': This idea could reasonably be described as, uh, 'not novel'.
- '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.
- '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'.
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..."
Re: The Future Database
#7If 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.
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?
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?
Re: The Future Database
#8My dream was having a database like AWS DynamoDB, but with analytical capabilities built-in the API.
I think you are talking about HTAP(https://en.wikipedia.org/wiki/Hybrid_transactional/analytica...). There are already decent products on the market. But don't expect 100% analytical capabilities like BigQuery / Snowflake. There are tradeoffs.
If your workload fits the model well (mostly OLTP, but occasionally some with heavier aggregations, etc.), it would be awesome.
Example: TiDB
Re: The Future Database
#9What 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).
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.
Re: The Future Database
#10I can't make sense of lots of this. - 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. - 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 comput…
What does 'serverless' mean exactly?
1) i think server-less, means ops-less, no manager of server even at scale,maybe you need optimization query but not to deploy databases, migration and that.
3)Scale should not come at the cost of performance
is easier said than done, is the same idea automatic cache an thinks like this
2) i think the same
i will still use monolith like PostgreSQL use a doubt have more intensive workflows than medium.