How Modern SQL Databases Are Changing Web Development: Part 1
blog.whimslab.io
blog.whimslab.io
You could cache computed data closer to the user (on the edge) to avoid the longer round trip to your host, but putting your Node backed closer to the user just makes the trip from backend to the DB longer? Is the latency from edge to DB really that much better? Maybe what you're optimizing for is something like serving cached data behind auth which does require some business logic (hence the caching of part of the DB at the edge as well)?
Seems cool but back to the article which claims that it changes modern web development. Modern web development sounds for the most part the same. Maybe the article can be called "How Modern SQL Databases Are Enabling Distributed Web Development"?
However, if your server is doing other work, it might be useful to be close to users even if the data isn't. This is why fly.io sponsors stuff like Phoenix Liveview or Laravel Livewire.
You mentioned Liveview and Livewire. Both are great and they would work equally well in any context, not exclusively a server less front-end.
I would propose that switching to a more efficient programming language (i.e. not using Elixir or PHP) and investing in better data structure optimization would result in equal if not better performance improvements than investing the same amount of time wrangling data replication issues and infrastructure maintenance caused by edge compute.
To the point of the original article, modern web development remains the same: start with a single server, server-side render your content, and expand when the need arises. What we're talking about in the comments is performance web development for geographically distributed audiences (for instance, if you're building a global social network).
You're right that the question is whether you want the high-latency link to be between the web browser and the web backend, versus the web backend and the database.
Either way works; it's just a matter of where you're going to spend effort reducing round trips. For database driver developers, optimizing for minimizing round trips is new, but they're making progress. As an app developer, you can use stored procedures to reduce round trips, or even have app logic in both places.
As you say, serving a result from an edge cache is a way to avoid any database round trip. This brings up issues around cache invalidation that haven't really been tackled yet; with Postgres you could use listen/notify, but it assumes a persistent connection that isn't there for these new drivers.
An alternative would be to use read-only database replicas, but that seems relatively heavyweight compared to a bit of local caching.
I can also imagine how you can have localized datasets with a centralized auth database, for instance. That way, you have something akin to sharding of the dataset to bring real-time functionality closer to a global user-base. For example, you can have an edge game server with a local state serving 20-30 players close to their physical location.
I wouldn't recommend this for 99% of web development tho.
Is there some kind of SQL client library that can somehow cache records from the DB, and P2P cache with other application servers, but then make sure everything is synced with the main server?
Wouldn't it be ideal to have just the parts of the DB that each user needed kept close to that user?
App Engine (which was the first popular serverless platform, before the term was coined) included a datastore about 7 years prior.
It probably avoids recognition because it was tied to App Engine, which wasn't serverless by itself, and predated the popularization of the term serverless. I can identify a few other serverless NoSQL databases that predated the serverless hype: Azure Storage Tables and CosmosDB (known as DocumentDB back when it was released in 2014) for one. I haven't used DynamoDB back then, but it seems like it was also serverless from day one[1].
I think the author really wanted to say "Serverless SQL databases are not a new thing. AWS launched Aurora back in 2017 [...]". That might check out if you don't count Cloud Spanner as "true" SQL[2], but I'm wouldn't be surprised if you'd find someone who has implemented a niche SQL database service that wasn't provisioned and kinda supported scaling up as needed.
[1] "Amazon DynamoDB lets you specify the request throughput you want your table to be able to achieve (your table’s “throughput capacity”). Behind the scenes, the service handles the provisioning of resources to achieve the requested throughput rate. Rather than asking you to think about instances, hardware, memory, and other factors that could affect your throughput rate, we simply ask you to provision the throughput level you want to achieve and we handle the rest."
[2] Amazon only launched Aurora on 2018, even though they announced it in late 2018. Cloud Spanner was released a full year before, and Spanner was running internally on Google datacenters, possibly with serverless provisioning, since 2012.
Yes it was. I’m not sure how long you’ve been doing serverless for but App Engine’s entire concept was stateless functions.
Using App Engine's datastore could often be frustrating due to high latency. Hopefully these new database services will do better. At least you can write stored procedures.
Aurora certainly did that earlier, and there were probably other earlier examples also (funny, because author mentioned Aurora upthread).
> in edge environments because, for every incoming request, a new runtime is spawned to serve it
Said that way, it's hard not to think "CGI-bin on a server nearest the user (because webscale)". Coming soon: "the all new Persistent Edge, a runtime that actually stays up between requests, on a server nearest the user (because webscale) optimizing away startup costs!"
No I don't. They just have you pay 10 times the regular price while providing 10% of regular performance
serverless has mostly been hype and snake oil for me
Nothing beats a beefy box of metal
Why wouldn't you use some cloud offering where you can get many of these for cheap if your data is not large?
Few people run everything themselves. Most use existing datacenters or rent the hardware. Then its basically the same as using a VPS from a cloud provider when it comes to difficulty and expertise.
"cheap" is relative, if your data is not large (gigabytes) then cost will likely be much smaller compared to expenses on engineer supporting custom solution.
> if the uptime is less than 99.95 %
It doesn't mean their services experience this downtime. They have their reputation supporting revenue on the line. Customers will go somewhere else if experience frequent downtime.
But the point is that with custom pgsql installation it is nontrivial to setup and support any kind of fault tolerance, plus you have a chance of all other kind of outages: network, your hosting provider, etc.
Buying cloud offering with one click looks like no brainer base line.
So instead of "set xact_abort on" being a command setting one of a hundred possible 100 stateful connection flags, such flags would be part of every network roundtrip (as it is with HTTP).
Of course long lived DB transactions, temporary connection scoped tables, etc would need to be adjusted a bit in approach. But a shift towards SQL over RPC is certainly not impossible.
And long lived, client managed database transactions are worse performance wise than doing the transaction in one roundtrip; SQL is powerful enough that stored procedure-style transactions with parameter tables can do anything -- and for cases they cannot, optimistic concurrency control should usually be chosen instead anyway.
The cases where a long lived/client managed SQL transaction is NEEDED is rather seldom.
One could always use MySQL like HTTP; make a connection, authenticate, request a query, get the response, and close connection. On Postgres this is harder due to per-connection process overhead, but solutions like pgbouncer were made exactly for this.
But here's the fundamental difference: HTTP expects large numbers of disparate clients from literally anywhere with varying network quality/speed, and connection overhead would totally swamp your servers if they were stateful. Memory and file descriptors would quickly get in short supply.
Database access is inherently different. You shouldn't have random clients; you have a small, fixed set of client services and developers/admins connecting over a datacenter backplane, querying over and over and over again. The overhead of establishing/tearing down the sockets and re-authenticating becomes a performance bottleneck.
Folks don't create database connection pools because they're bored; they solve a very real and measurable architectural concern, just like HTTP pipelining did years ago and what HTTP/2 addresses through multiplexing: connection build up and tear down overhead. HTTP/3 goes further by avoiding TCP altogether in favor of custom connection handling over UDP.
But HTTP/3 just handles web assets. We regularly expect errors where we need to hit the reload button. SQL usage is markedly different. There is more of an emphasis on reliability at every step. Hitting a lock and retrying is very rare by comparison in the database world relative to the HTTP space. It happens (and it's a PITA), but it's nowhere near the norm.
As for transactions, you appear to regard them as a "sometimes" thing when if fact they're an "every time" thing. Every SELECT, INSERT, UPDATE, or DELETE, no matter how trivial involves a database transaction. They have to in order to enforce ACID.
I've written a few basic HTTP 1.x servers over the years in a few different languages. Fun exercise. I highly recommend it to get a better understanding of how the protocol works and common design tradeoffs. ACID databases are different. Very different. Mind bogglingly different. Orders of magnitude more complex even among the simplest. Compare the smallest, most lightweight web server you can find to SQLite or H2.
Well, you have a HTTP connection pool too, but they are not stateful in the way SQL connections are at all. You can send several requests after one another on the same HTTP connection, but the next request does not remember the previous one. Each request stands "on its own".
Which is very unlike SQL. And, client mamaged transactions build on this: They are stateful, each session can only hold one transaction at the time, and some buggy badly written code can thus easily go wild and fill up the connection pool and either a) take down that backend instance (if the size is capped) or b) use A LOT of connections and risk taking down the database.
With HTTP, the connection is held for as long as the network roundtrip then goes back to the pool.
With SQL, how long a piece of code holds on to a connection is unbounded. (If you use client managed transactions, or hold to a connection for temp tables or other reasons.)
• Keep-Alive has entered the chat • HTTP pipelining popped in • Connection multiplexing has entered the room • Web Sockets pokes head in • Server-Sent Events chimes in as well
And yes, again, the connection model for thousands or millions of disparate IPs from the Internet will obviously be different from resources acting on a network within a closely controlled datacenter. You claim to know all this but seem to gloss over these important points.
Also, "edge" means edge deployment environment/runtime like CloudFlare workers, Vercel Edge Runtime, etc. Not sensors, etc.
I totally get the HTAP argument now. I have absolutely zero anxiety about some rogue select causing trouble in a reporting context because of how trivial everything became. Things like adding read replicas for one-off reporting needs is a non-event now.
We use caching to store data and run SQL compute at the edge. It is wire protocol compatible with various databases (Postgres, MySQL, MS SQL, MariaDB) and it dramatically reduces query execution times and lower latency. It also has a JS driver for SQL over HTTP, as well as connection pooling for both TCP and HTTP.
> PolyScale automatically and intelligently caches or invalidates data close to where it is being requested.
I don't see how cache invalidation happens at all unless all changes go through PolyScale. What about making a change to the database directly?
If PolyScale can see mutation queries (inserts, updates, deletes) it will automatically invalidate, just the effected data from the cache, globally.
If you make changes directly to the database out of band to PolyScale, you have a few options depending on the use case. Firstly, the AI, statistical based models will invalidate. Secondly, you can purge - for example after a scheduled import etc. Thirdly, you can plug in CDC streams to power the invalidations.
Feel free to ping me if you would like to dig in deeper (ben at) and this document provides more detail on the caching protocol: https://docs.polyscale.ai/how-does-it-work#caching-protocol
This blog also goes in to detail on how invalidation works: https://www.polyscale.ai/blog/approaching-cache-invalidation...
NoSQL databases got rid of many useful things when they replaced SQL with JSON query languages and simplified SQL dialect, but I think they got a net positive when they did away with statefulness and replaced that with a simple request/response APIs. With this small you can easily multiplex many in-flight requests on a TCP single connection, and let both the server and the client handle requests on-demand, without having to allocate any memory and threads that serve most of their time idling away. The client (and supposedly the server, if it's using io_uring) can run all I/O asynchronously and increase available concurrency even more.
In short, you can get more concurrency and better scaling predictability for the same hardware since you don't have to optimize the way your connection pools are balanced across different clients. It's really one of these few things which is pure fun and joy and unicorns and rainbows when I'm designing a service with a NoSQL DB.
Redis is well-known (and sometimes criticized) for being single-threaded, but managing a connection pool on the client side is still necessary, so my statement is obviously not true for ALL NoSQL databases. But it is at least true for Cassandra and as far as I understand for DynamoDB and Couchbase to some degree.
There are reactive and non-reactive based SQL dbs too. I know someone at Amazon working on one.
You can have state per connection and still use epoll or whatever. Even with NodeJS or Vertx you can open a connection against a worker pool, maintain state for that connection, and it doesn't require thread/process per connection. That's merely an implementation detail (and nice isolation for extensions etc).
I said "one area where NoSQL databases shine", "NoSQL databases got rid of many useful things", and "one of these few things which is pure fun [... with] NoSQL databases".
Not sure how can you interpret this as me saying that Relational DBs are bad or that MongoDB is great.
"MongoDB is Web Scale" ~5.5mins https://www.youtube.com/watch?v=HdnDXsqiPYo
However, there are always going to be legions of use cases for traditional database use, and the question continues to be, should everything that could need to scale massively use a NoSQL backend, or can some applications get by with something that looks like a traditional SQL architecture in 99+% of cases?
I think that many applications could be constructed with a NoSQL database as the backend for applications that are primarily reading content, while the applications that require the greatest access to CRUD functionality could interact with a SQL database using connection pooling to minimize resource utilization or latency at scale.
With this in mind, I could see applications where editing the backend is done in a SQL-based version of the database, while rendering content from the backend is done against a NoSQL version of the same database. There would probably be some momentary differences between the two, but the interface between the SQL and NoSQL version of the database could be a pipeline and therefore, could be optimized.
Did you notice significant improvements in terms of perf, features and pricing?
Not being able to reduce the storage size on RDS is a major pain point for us.
It should be that it's becoming easier to have a robust database (or job queue, or full text search, etc) on your premises, not have more and more go to the cloud.
Though it is true that managing your own infrastructure can be challenging, it is not inherently so. One can easily imagine self healing and self managing infrastructure, physical hardware deterioration and replacement aside.
EDIT: I want to clarify that I'm not denouncing the cloud. My point is simply that it should be easier to also manage your own fleet if you so choose. This could mean using VMs, bare metal or what have you. Even managing a fleet of VMs is nightmareish today.
It's not just about the hardware itself, that's the easiest part.
It's about building and maintaining the electrical/cooling/network infrastructure the servers require. It's about having multiple locations of that in case your building's power or network goes down/there's a flood/somebody steals all your stuff/whatever else.
Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud, you just do a lot of work yourself and get no guarantees and no flexibility. At that point, why not just go full cloud?
There’s no reason a modern fleet couldn’t detect failures in hardware and automatically order replacement from Amazon or whatever. This is not to say you won’t need personnel, but you would be surprised how much of the fleet management at AWS and GCP at least are brute forced (as opposed to being completely automatic). To their defense they have a far more complicated and diverse fleet than what I’m describing, which is sort of my point.
99% of customers just need a highly available setup for their stateful boxes (DBs) and some for their stateless services. And the great thing about this setup is you can extend the stateless bit (with the cost of latency) to the cloud more or less infinitely.
As far as the rest of your point about cooling and network - it's a good point, but for a workload that isn't a datacenter, in my experience the majority of outages aren't due to that - it's due to misconfiguration.
Take a personal house. How often does someone break into the average person's home? Pretty unlikely in a low crime area. Take internet. There are some areas in the United States where there are multiple 1Gbs or even 10Gbs internet providers, you could redundantly network. In any case it's not that the cloud shouldn't be used, it's just interesting the direction things are going.
Of course, if money isn't an issue by all means people should use serverless and cloud spanner and be done with it.
Ding ding ding, we have a winner!
Paying premiums for BigCloud means not paying salaries, not worrying about an outage that could happen while your seniors are on vacation, not needing to set up resilient internal processes and controls for datacenter management, not worrying about datacenter management compliance, etc. etc.
Needing to hire datacenter personnel is a problem and it is a problem that BigCloud solved.
I'm not saying there isn't value in the cloud. I'm saying most people are overpaying. BigCloud didn't solve this any more than paying employees in general to solve your problems. With the era of free money coming to the end, many companies will come to this realization themselves in any case. BigTech clouds have 50%+ margins - something will give eventually.
Any serious company is still going to have to pay oncallers, and admins with or without cloud. It's not like using the cloud absolves you from maintenance (pretty much every company with a valuation more than 100 million has an infrastructure team, and uses the cloud. So clearly the cloud doesn't mean you don't have to maintain your own infrastructure). And now we come back to my point - why isn't the fleet easier to maintain to begin with? I'm not even talking about bare-metal necessarily. Say you use VMs. Still a huge hassle.
Yes, the oligopoly, and the vendor lock-in.
Certainly won't be expecting the "advantage" of being able to outsource your sysadmins to somewhere else at the drop of a hat to be the thing that gives.
Vendor lock in at this level is not really an issue for most, trying to be agnostic will create more problems and time sinks
You need all the same people to manage the same software stack, regardless of whether the VMs sit on hardware you own or at an AWS rack. Nearly all the work is on the software side.
The physical bit of maintaining the boxes is a minimal percentage of the work. At various startups we usually didn't have anyone hired to do this work because there wasn't enough to justify a person. Most simple changes (like pull and replace a hot-plug drive) can be done by the colo personnel and for larger work someone would drive to the colo maybe once a month. You only start to need dedicated hardware maintenance personnel at a very large scale.
The premium you're paying for cpu and bandwidth at your BigCloud is so enormous that it'll easily pay many more salaries than the people you need even if you reach the scale of needing dedicated hardware people.
Hardware is unbelievably reliable, systems normally run for many years without any attention.
1. First of all, a good bare metal setup leaves much of the software fleet management able to be done remotely. So if you were there because of that then clearly this wasn't done right. I'm talking about SSH access at a bare minimum, and ideally out of band access as well.
2. I'd say the things that go wrong in a data center are plentiful, but should be predictable. Power, network or cooling related issues means you picked the wrong site or your vendor screwed you. That leaves us to the actual hardware. Sourcing good hardware is obviously critical. Modern Dell and HP enterprise machines should be giving you very, very reliable hardware assuming the beforementioned concerns are addressed. It is true that disks fail, and sometimes memory, but if you were there literally every day there is just a critical failure in your setup somewhere.
Even if you had a data center with literally a thousand machines. An uncorrelated failure happening every day is so unlikely that it's not really worth mentioning. Correlate failures could certainly happen. Bad batch of disks, etc, but still shouldn't result in you being there literally every day. I could imagine a series of bad days though, sure.
Except at the extreme high end of scale, you never do this yourself. Rent racks in a colocation. It's a very clean separation of duties. You handle all the tech work, they handle all the real estate upkeep.
> Or you rent a rack in a colo (or five)... But that's just a step away from going full cloud
What? Not even close. When you rent a rack in a colo you have 100% of the benefits of owning the hardware (much higher performance, much lower cost). Just because you let someone else do the A/C and generator maintenance (and other non-computer real estate logistics) doesn't make it anything at all like the cloud.
I mean... if you ignore the hard parts of self managing then self managing is in deed easier lol
For bare metal would something like Equinix fit?
> Even managing a fleet of VMs is nightmareish today.
What about fly.io?
I love their model, but execution lacks.
That said, if they can get a handle on reliability and uptime, its extremely compelling
The biggest challenge when you have on-premise infrastructure is battling managers to get an additional server.
I have seen managers laughing at my team leader when he asked for a server to do some QA. We needed the server to perform some tests for a critical product. They even had the audacity to say "Hey Manager Bob, how long have you asked for a server?" Manager Bob answered "It's been month's now"
Granted I think that's an extreme example but I don't doubt it was a common occurrence back in the day. Now I also have worked on enterprises where asking fora server (Or RAM increment in a given server) is as easy as submitting a ticket and waiting for a FEW DAYS.
Cloud is more expense on the long run, but it sure gives you agility to do things.
What worked for cloud won't work for edge in most cases. Having to do processing locally means processing on your own hardware.
We've seen this as the reason a lot of companies are adopting tools like NATS.io to be more cloud agnostic and/or be able to practically run at the Edge.
True serverless would mean a return to dumb interchangeable servers: static progressive web applications hosted by dumb static http servers (e.g. github pages), connecting to interchangeable data storage (e.g. W3C solid pods), with client-side peer to peer synchronization of data using CRDT algorithms (e.g. Automerge, YJS, ...). When I think of the word "serverless", that's what comes to mind.
I'd be really interested in an open standard that would expose something like IndexedDB on the client-side while enabling sync and basic business logic. Maybe inspired by the firebase API.
A GitHub page is in no way serverless. It’s totally inaccessible without internet and requires literally a remote server to function. Ironically GitHub page is more similar to the marketing definition of serverless.
Should be. But I'm yet to see a PWA like that; all I've been victim of experiencing had all meaningful operations involve a round-trip through the cloud.
And since the major cloud providers have something like that, your are no more hostage with these than you are with any other cloud stuff.
There is no "true serverless", there is only the usage of the word that the majority of people use, which is to mean server-as-a-service. Nobody suggested it's a way to avoid lock-in. It's a way to avoiding managing servers.
I don't see the problem here.
I succumbed to the SQLite hype train in 2020 when every other post on HN was about it. I started building things with it. First, small things. Then bigger things.
Now I’m at the point where I default to starting most things with SQLite unless there’s a really good reason. It’s incredible how far SQLite can take you. It feels almost like a cheat code. Wish I had jumped on the train years ago.
Is it really a hype train when every 6-12 months since I joined this site there has been a ~1month period of sqlite on the front page every day? At some point a repeated and perennial "hype cycle" might just in fact be enthusiasm about a good product.
It's a confusing term, but it's not the first one. We survived "JavaScript", and complaining it's not related to Java at all stopped being fashionable along with flip phones and it's only ever done as a joke[1]. I foresee the same thing would happen for serverless in 10 years, and we'll get tired of complaining that this term sucks.
FWIW, we just have to internalize that serverless means "a service where you don't have to provision and manage your cloud servers and you don't even know how many of them are out there", just we collectively internalized that the HTTP Authorization header is the header responsible for Authentication.
As for more lock in, how? If I use aurora postgres serverless I am 100% free to migrate to a regular postgres server, even on another provider.
Nobody is thinking there is no server, except maybe my grandmother.
Aurora does add bells and whistles on top of vanilla Postgres that you’d be hard-pressed to find from other DBaaS vendors.
Sure, you can pg_dump and pg_restore to another provider but you lose all the goodies that made you choose Aurora in the first place.
For clarity, I’m a long-time happy user of Aurora and spend $super_big_money on it. Worth every penny IMHO.
I'm honestly curious as to which features you find most compelling that can't be found in vanilla Postgres.
But that single DB is just a piece of the business puzzle. Networking, web applications, even backups. That's hard to migrate (And hard here means it will take massive effort and time)
Good teams have plans in case they need to migrate. But I think not all teams are prepared for such scenario.
You can go ahead and call it "server as a service" (and have everyone look at you funny) while the rest of the development world cares zero about the pedantry and continues to build serverless applications without worrying about planning around or maintaining a server.
"Serverless uses servers!" can be added to the list of predictable comments, along with "The Economics Nobel isn't real!" and "Correlation isn't causation!". We get it, it doesn't need to be repeated every time an adjacent subject is discussed.
It used to be that the so called “Computer Scientists” would be naming these things, but now it seems that its just another marketing department and lots of susceptible developers buy into that.
You can install postgres in a AWS EC2, it's in the "cloud" but you still have to do all the sysadmin work yourself.
Or you can use a "serverless" postgres and let the provider do the sysadmin work for you. I guess you could call it "postgres as a service".
I prefer "as a service" or "managed" instead of "serverless". Not a big fan of the term for the reasons you mentioned.
If you have another model that you think is better, why don't you come up with a name for it, instead of trying to co-op a perfectly cromulent term that is already in wide usage?
There is a difference between an abstraction that allows the user to ignore X, and the actual absence of X. Modern car engines, for example, are reliable enough that most drivers don't have to worry about them. But it's still a mistake to call a car with a reliable engine "engine-less".
A driverless vehicle doesn't require me to add a driver to reach a destination. A serverless solution doesn't require me to add a server to achieve the goal. Something is still driving the car, something is still serving the data. But it's out of my hands.
I found the gateway drug was a robot that could do simple things, then modifying the code to make it do different things.
https://chromeunboxed.com/google-shutting-down-grasshopper-c...
Some languages make building harder than others but containers can obviate a lot of that difficulty even if the runtime target is bare metal.
that sounds wonderful. my best childhood memories are learning physics from my bad (more than in school), and I'm a physicist now
I did Ctrl+F search for "edge" in this thread's article and all 23 instances of it seems to be talking about computing on an edge node such as a CDN. Example sentence: "Edge-Ready Drivers -- Regarding supporting connections from the edge, [...] Things have been changing fast. PlanetScale announced its “Fetch API-compatible” database driver a few months ago, making it fully useable from Vercel Edge Runtime and Cloudflare Workers."
Can you point to where you think he used "edge" to be synonymous with Chrome/Firefox?
I remember being at a conference and everyone being amazed that Chick-Fil-A dared the impossible - putting K8S clusters at each store to run operations. Lol.
This business always makes me laugh.