[HN Gopher] How Modern SQL Databases Are Changing Web Developmen...
___________________________________________________________________
How Modern SQL Databases Are Changing Web Development: Part 1
Author : thunderbong
Score : 150 points
Date : 2023-08-24 09:25 UTC (13 hours ago)
(HTM) web link (blog.whimslab.io)
(TXT) w3m dump (blog.whimslab.io)
| holoduke wrote:
| In the meantime i am learning my 12 year old one how to install a
| debian server. Install postgresql and some scripting languages.
| Then we proceed to make a simple website with a simple backend.
| There is so much more joy into learning stuff from this level.
| hackernewds wrote:
| "I am teaching" :)
|
| that sounds wonderful. my best childhood memories are learning
| physics from my bad (more than in school), and I'm a physicist
| now
| whispersnow wrote:
| Your kid is way too advanced! I am sticking with Code.org
| verdverm wrote:
| The Grasshopper App is another good one
| colecut wrote:
| Is this the one Google shut down a couple months ago? =-\
|
| https://chromeunboxed.com/google-shutting-down-
| grasshopper-c...
| verdverm wrote:
| dammit...
| [deleted]
| panarky wrote:
| If I'd tried to start my kids on how to install software on an
| operating system, and how to write bash and SQL, they would
| have lost interest instantaneously.
|
| I found the gateway drug was a robot that could do simple
| things, then modifying the code to make it do different things.
| ppeetteerr wrote:
| This is the way. Too many engineers are disconnected from the
| metal.
| tracker1 wrote:
| I wouldn't be against taking the next step to understanding
| and using Docker, then docker-compose for such a thing. One
| can get a lot of use out of a system this way.
| ppeetteerr wrote:
| You could branch out in a lot of directions from here.
| Compiling from source is another option, or messing around
| with config files. Depends on where you want to go in the
| education.
| giantrobot wrote:
| Docker is still helpful even when you want to compile for
| source. Something that's simple with containers but
| maddening on bare metal is build or runtime configs where
| different versions of packed/libraries are required. A
| container lets you have a super customized build
| environment for a single application that can spit out a
| binary that'll run on bare metal but might otherwise
| pollute the machine's build config.
|
| Some languages make building harder than others but
| containers can obviate a lot of that difficulty even if
| the runtime target is bare metal.
| muxator wrote:
| There are simpler (maybe not easier) solutions for that.
| ppeetteerr wrote:
| It took me a while to get some context here but the article makes
| sense. Maybe more outside the topic but related: why would you
| put business logic closer to the user when that's rarely the
| performance bottleneck?
|
| 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"?
| skybrian wrote:
| Yeah, the headline isn't great, but it's describing something
| real that database service providers are working on.
|
| 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.
| ppeetteerr wrote:
| Yeah, DB replication and caching would be a pain in this
| scenario. Akamai cache busting is challenging enough in
| complex cases.
|
| 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.
| satyrnein wrote:
| If your server is just fetching data, then it doesn't seem like
| much benefit to have the server close to the user unless the
| data is also close to the user at least some of the time
| (caching, distributed db, etc).
|
| 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.
| ppeetteerr wrote:
| Totally agree that function locality is important, especially
| if latency reduction is your biggest opportunity. Edge
| compute feels like a niche problem for most businesses, and
| it comes with high overhead costs in setup and maintenance.
|
| 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).
| dagss wrote:
| I wish SQL DBs had some focus on implementing stateless
| protocols. Is there any reason the "connection pool" could not be
| built into the same service as the SQL database, and start a move
| to an RPC protocol instead of stateful protocol?
|
| 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.
| unscaled wrote:
| Connection pooling is one area where NoSQL databases shine.
| Classic SQL is extremely stateful. It was designed was designed
| in a very different age when it was expected to mostly be used
| directly by programmers and non-technical users and be as
| friendly as possible. The SQL standard defines some state that
| must be stored along with each session, such as temporary tables,
| current schema, current timezone etc. This means that sessions
| have a pretty significant memory overhead and generally require a
| thread on the server side (and probably the client-side too).
|
| 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.
| winrid wrote:
| Mongo, one of the largest NoSQL databases, uses a thread on the
| server per connection, and is known for using around 1mb per
| one of those connections.
| unscaled wrote:
| Frankly speaking, Mongo is probably the worst NoSQL database
| out there, and it has given bad rep for other NoSQL database
| which do have their use cases, such Cassandra, DynamoDB,
| Couchbase and Redis (yes, let's not forget that Redis is also
| a NoSQL database, without the hype).
|
| 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.
| winrid wrote:
| No statements will apply to all of anything, just thought
| I'd clarify since in ten years of working with nosql by
| large the largest deployments were with Mongo. Bad luck
| maybe :)
|
| 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).
| posnet wrote:
| Everybody knows relational databases don't scale because they
| use joins and write to disk. Relational databases weren't built
| for Web Scale. MongoDB is Web Scale. You turn it on, and it
| scales right up. Shards are the secret ingredient in the Web
| Scale sauce.
| unscaled wrote:
| Did I ever say that?
|
| 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.
| nsp wrote:
| He's referencing the infamous "mongodb is webscale" video
| from about a decade ago
| vlod wrote:
| For those too lazy to search:
|
| "MongoDB is Web Scale" ~5.5mins
| https://www.youtube.com/watch?v=HdnDXsqiPYo
| endisneigh wrote:
| The development of things saddens me. (re: this whole thing about
| serverless and edge).
|
| 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.
| andrewjl wrote:
| > This could mean using VMs, bare metal or what have you.
|
| For bare metal would something like Equinix fit?
|
| > Even managing a fleet of VMs is nightmareish today.
|
| What about fly.io?
| no_wizard wrote:
| fly.io has had alot of reliability problems in the past, with
| lots of users on HN and elsewhere talking about a whole host
| of problems from disappearing VMs to bad backups to poor
| uptime.
|
| I love their model, but execution lacks.
|
| That said, if they can get a handle on reliability and
| uptime, its extremely compelling
| codegangsta wrote:
| While there are lots of cloud providers also trying to be edge
| providers, I would argue that "The Far Edge" is a great
| opportunity to improve and develop infrastructure that is
| easier to run on your own hardware.
|
| 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.
| [deleted]
| m_0x wrote:
| > it is true that managing your own infrastructure can be
| challenging, it is not inherently so.
|
| 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.
| NorwegianDude wrote:
| You don't have to go all in. You can have your own servers
| and rent when you need additional capacity. Best of both
| worlds.
| BiteCode_dev wrote:
| There is a middle ground between the cloud and on premise.
| You can get a VPS or a dedicated server from a traditional
| host. If you have a running tab with them, which is common
| for operations like this, you get your servers in a few
| hours, sometimes minutes.
| letsdothisagain wrote:
| Yeah the cloud is a lovely weapon against the BOFH. They
| smarten right up when you shrug your shoulders and say "Oh, I
| guess I'll just buy some cloud."
| datahead wrote:
| oh, your luser account is 'letsdothisagain', great
| thannnnks. I'll take care of that right now.
| throwaway98158 wrote:
| Can you explain how can physical hardware concerns be handwaved
| away?
|
| 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?
| jjav wrote:
| > It's about building and maintaining the
| electrical/cooling/network infrastructure the servers
| require.
|
| 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.
| verdverm wrote:
| On GCP, they will live migrate your running VMs to new racks
| and you won't likely know unless you look for it in the logs,
| super nice feature, I once got bit by AWS and a disk physical
| failure, had to migrate myself (really a nuke and recreate
| since we couldn't do anything with the VM)
| endisneigh wrote:
| This is not the 90s - monitoring and alerting are far more
| robust, and supply chains far more just in time.
|
| 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.
| solatic wrote:
| > This is not to say you won't need personnel
|
| 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.
| icedchai wrote:
| You are right, but this was also solved by "dedicated
| server" folks years before cloud was a thing.
| endisneigh wrote:
| You're thinking about it the wrong way. Sure you're not
| paying salaries, but now you're paying for experts who
| understand the cloud and you're paying more for those
| people compared to datacenter people. At Azure I was
| surprised how many data center people didn't even have a
| college degree and how little they were paid. Ultimately
| the only thing that matters is the total cost. To take
| true advantage of the cloud you need to use cloud
| specific technologies - serverless being the greatest
| example. Cloud VMs are neat and all, but in a sense it's
| the worst of both worlds.
|
| 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.
| [deleted]
| DANmode wrote:
| > BigTech clouds have 50%+ margins - something will give
| eventually.
|
| 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.
| verdverm wrote:
| How often do people actually migrate clouds?
|
| Vendor lock in at this level is not really an issue for
| most, trying to be agnostic will create more problems and
| time sinks
| jjav wrote:
| > Paying premiums for BigCloud means not paying salaries
|
| 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.
| icedchai wrote:
| Yep, in the old days (almost 20 years ago now), I worked
| at a startup with its own racks. We'd go up there once a
| month to swap some drives. In my 5 years there, I had to
| use remote hands exactly twice to reboot a machine. A few
| other times, one of the servers froze but we were able to
| reboot it with ILO. This was 3 racks, about 30 machines
| spread between them (definitely a bunch of empty space,
| too.)
| throwaway98158 wrote:
| Happy you, I was in the same situation but I was in the
| server room daily. Practically every day something went
| wrong.
| icedchai wrote:
| How many systems did you have? What sorts of problems?
| endisneigh wrote:
| I am genuinely curious about both the software and
| hardware stack if you were there every day due to
| something going wrong.
|
| 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.
| jjav wrote:
| Either you had thousands of machines (at which point is
| totally makes sense to hire a dedicated person with all
| the money you're saving) or the site had environmental
| problems (dirty power, bad cooling, etc?) causing the
| issues.
|
| Hardware is unbelievably reliable, systems normally run
| for many years without any attention.
| spion wrote:
| There is some development on that front too. For postgres,
| check out CrunchyData's postgres operator
| (https://access.crunchydata.com/documentation/postgres-
| operat...) where with a single config file you get a HA
| database with read replica(s), connection pooling via pgbouncer
| and multiple backup targets via pgbackrest with cloning and
| point-in-time recovery
| internet101010 wrote:
| You can also use pgvector with langchain to create a weird
| version of search if so inclined.
| verdverm wrote:
| I personally like the Zalando operator better, you can add
| databases and users by updating the CRD, feature parity
| between the two on HA is pretty good
|
| https://github.com/zalando/postgres-operator
| acedTrex wrote:
| > physical hardware deterioration and replacement aside.
|
| I mean... if you ignore the hard parts of self managing then
| self managing is in deed easier lol
| endisneigh wrote:
| Self managing isn't hard just because of that. You could use
| VMs with your cloud provider of choice and my point stands.
| LamaOfRuin wrote:
| I'd argue that has gotten hugely easier. The problem is we
| have gotten hugely more demanding as well, so it ends up
| still being difficult.
| ggregoire wrote:
| Someone migrated from RDS to Neon (or similar service)?
|
| 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.
| nikita wrote:
| Please email nikita@neon.tech we will share examples and help
| you out
| danesparza wrote:
| None of these things are new. Connection pooling (in particular)
| has been around for decades. Perhaps the author just recently
| discovered it?
| seedless-sensat wrote:
| The author also mentions Neon is the first "pioneer" to do
| disaggregated storage. It is mentioned in the 2006 Bigtable
| paper, and probably earlier than that too.
| butlerm wrote:
| Databases like Oracle Parallel Server were doing
| disaggregated storage more than a decade before that.
| nailer wrote:
| > Serverless databases are not a new thing. AWS launched Aurora
| back in 2017
|
| App Engine (which was the first popular serverless platform,
| before the term was coined) included a datastore about 7 years
| prior.
| unscaled wrote:
| [tl;dr: Serverless provisioning for data is far from a new
| concept, but it wasn't called "serverless" before serverless
| compute (functions) appeared. OP probably meant that Aurora was
| the first serverless _SQL_ database, but even that statement is
| debatable.]
|
| 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.
| nailer wrote:
| > it was tied to App Engine, which wasn't serverless by
| itself
|
| Yes it was. I'm not sure how long you've been doing
| serverless for but App Engine's entire concept was stateless
| functions.
| skybrian wrote:
| Not necessarily stateless. You could cache things in global
| variables within the process, as well as using memcache.
|
| 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.
| Transpire7487 wrote:
| and I'm still using regular postgres just fine for over a decade
| and no plans to stop any time soon
|
| serverless has mostly been hype and snake oil for me
|
| Nothing beats a beefy box of metal
| riku_iki wrote:
| what is your story for fault tolerance and replication
| (hopefully cross geo zone). Do you set and run everything
| yourself? How much effort(including learning curve) and
| expertise does it require?
|
| Why wouldn't you use some cloud offering where you can get many
| of these for cheap if your data is not large?
| NorwegianDude wrote:
| What makes you think cloud is cheap, or reliable? AWS lambda
| does not provide any guarantees other than compensation if
| the uptime is less than 99.95 %. That is ~22 minutes/month.
| It's terrible. If it was reliable they would provide better
| guarantees. How long since a major outage? A couple of
| months.
|
| 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.
| riku_iki wrote:
| > What makes you think cloud is cheap, or reliable?
|
| "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.
| daveaiello wrote:
| I have used both SQL and NoSQL databases in the cloud. My sense
| of the situation at the moment is that some NoSQL databases have
| begun to focus on AI and LLM applications, apparently in order to
| provide scalable storage to these applications, which can be used
| for things like the persistence of state across many
| interactions.
|
| 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.
| FpUser wrote:
| >"I hope you find the advances of these serverless and edge-ready
| databases as exciting as I do."
|
| No I don't. They just have you pay 10 times the regular price
| while providing 10% of regular performance
| [deleted]
| smallerfish wrote:
| > separation of "Compute" and "Storage". Yes, I'm explicitly
| talking about Neon here since it was the first to pioneer the
| concept
|
| 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!"
| worksonmine wrote:
| In other words, you should cache and shard your data. I hate this
| industry.
| bob1029 wrote:
| The "serverless" angle is super compelling for us. We don't have
| a lot of time to think about this kind of thing. Being able to go
| from 0 to 100TB with compute/storage scaling automagically is
| simply bananas value. I don't really care what it costs anymore.
| I know the herd will mostly protect us with regard to pricing
| (our utilization is paltry compared to advertised use cases).
|
| 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.
| lagniappe wrote:
| Ah, so this is web-scale, at long last
| endisneigh wrote:
| Though serverless is compelling, the few cases where I've
| actually seen someone need the sudden increase in compute with
| both Firestore and DynamoDB, it failed to deliver performantly.
| That being said this was in the 2010s, I'm sure things have
| improved by now.
| edgyquant wrote:
| Serverless is a footgun. The limit on response size means
| people who don't build things with them in mind suddenly
| can't scale when they get actual customers.
| Joeri wrote:
| I keep rejecting this definition of "serverless" in my head.
| There's just as much server, it's just that someone else owns and
| operates the server, and holds your data or application hostage
| when they want to. This thing currently called "serverless" is
| more like "server as a service", and creates more lock-in than
| what came before.
|
| 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.
| falcor84 wrote:
| Hear hear.
|
| 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.
| gelatocar wrote:
| Not sure if you're thinking more of an official standard but
| PouchDB is open source and sounds similar to what you're
| talking about: https://pouchdb.com/
| itsoktocry wrote:
| > _This thing currently called "serverless" is more like
| "server as a service"_
|
| 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.
| tacker2000 wrote:
| Sorry but this is just buzzword bingo. Why not call it cloud?
| Why throw around some ambiguous and meaningless term?
|
| 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.
| ggregoire wrote:
| cloud vs. serverless:
|
| 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".
| mpol wrote:
| That is simply a managed server.
| tacker2000 wrote:
| How is that server "less"? Just because you didnt install
| it using apt-get? Its still a server. It still uses a
| bare metal machine running a VM in some datacenter that
| is accessible remotely.
| ggregoire wrote:
| I was just commenting about the difference between
| "cloud" and "serverless", because you said "Why not call
| it cloud?".
|
| I prefer "as a service" or "managed" instead of
| "serverless". Not a big fan of the term for the reasons
| you mentioned.
| [deleted]
| FoomFries wrote:
| Since everything is a car analogy...
|
| 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.
| tomjen3 wrote:
| I did the same for a long time, because it was obvously
| marketing BS, but when I looked into it a bit I realised that
| it was actually quite useful to have "programmable HTTP
| endpoints" og "Chron jobs in the cloud" where you don't have to
| worry about the details of running them. If they only run
| occasionally, they can be quite cheap too.
|
| 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.
| anewlanguage wrote:
| I really don't get the semantic arguments against serverless.
| The name perfectly describes what it is: an abstraction where
| the developer doesn't have to worry about a server. It's really
| that simple.
|
| 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?
| lisper wrote:
| > The name perfectly describes what it is: an abstraction
| where the developer doesn't have to worry about a server.
|
| 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".
| paulddraper wrote:
| Brb gonna start up my serverless MS Word.
| [deleted]
| floodle wrote:
| This seems to be getting pendantic about nomenclature.
|
| 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.
| abruzzi wrote:
| When I saw serverless, my mind when right to ultra
| lightweight database-as-a-library like SQLlite. Not AWS or
| azure cloud.
| leesalminen wrote:
| Same here. In my formative years I was led to believe you
| had to use a "real" RDBMS for everything- MySQL or
| Postgres. Anything else was just a toy not suitable for use
| in the real world.
|
| 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.
| sophacles wrote:
| > I succumbed to the SQLite hype train in 2020 when every
| other post on HN was about it
|
| 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.
| unscaled wrote:
| When "serverless" just got started and mostly focused on
| running functions with infinite (and automatic)
| scalability, the term "Functions-as-a-Service" (FaaS)
| seemed like a good competitor for a while, but that ship
| has long sailed.
|
| 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_.
|
| [1] https://news.ycombinator.com/item?id=36782761
| endisneigh wrote:
| A strange take. If you're going to be pedantic you might as
| well be correct - server less would mean literally that, no
| server required, e.g. Apple Notes or Microsoft Word 2010 and
| more similar to the end of your comment (a solid pod isn't
| serverless either btw) and CRDT is totally irrelevant here -
| you could use CRDTs and still not have an offline application.
|
| 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.
| Joeri wrote:
| If we're going to be pedantic, let me point out that for a
| pwa a connection to the server is only required for initial
| install and successive data synchronization, so the operation
| of the web app I described is indeed literally serverless
| outside of those edge cases.
| TeMPOraL wrote:
| > _for a pwa a connection to the server is only required
| for initial install and successive data synchronization, so
| the operation of the web app I described is indeed
| literally serverless outside of those edge cases._
|
| 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.
| bearjaws wrote:
| I always love this take as if AWS / GCP / Azure / literally any
| data center couldn't already do this to you.
|
| 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.
| leesalminen wrote:
| I feel like Aurora might be a bad example for anti-lock-in.
| Perhaps vanilla RDS Postgres would be a better one?
|
| 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.
| m_0x wrote:
| One single database cluster might not be an issue to migrate
| to another cloud provider.
|
| 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.
| toyg wrote:
| This repurposing of "edge" to mean "browser" continues to confuse
| me.
| mvandermeulen wrote:
| I'm fairness his browser could be called edge too
| Spooky23 wrote:
| It's funny as servers locally or regionally, co-located close
| to users, was this stupid legacy thing a couple of years ago.
|
| 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.
| Ensorceled wrote:
| Yeah, "edge environment" threw me.
| jasode wrote:
| _> This repurposing of "edge" to mean "browser" continues to
| confuse me._
|
| 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?
| [deleted]
| ggregoire wrote:
| Yea same. I was confused when the article said "edge
| environments can't connect to a database via TCP".
| midiguy wrote:
| I kind of hate how this article did not once clearly explain
| what it meant by the nebulous term 'edge'.
| [deleted]
| say_it_as_it_is wrote:
| Modern implies progress. Serverless isn't progress. It's not the
| rising tide that lifts all boats.
| _ben_ wrote:
| At PolyScale [1] we tackle many of the same challenges. Some of
| this article feels a little dated to me but the data
| distribution, connectivity and scaling challenges are valid.
|
| 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.
|
| https://www.polyscale.ai/
| skybrian wrote:
| This pitch is rather opaque to me. How does cache invalidation
| actually work?
|
| 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?
| _ben_ wrote:
| Thanks for the questions. At a very high level, the AI uses
| statistical models that learn in real-time and estimate how
| frequently the data on the database is changing. The TTL's
| get set accordingly and are set per SQL query. The model
| looks at many inputs such as the payload sizes being returned
| from the database as well as arrival rates.
|
| 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...
| avinassh wrote:
| This is interesting! How does polyscale works, especially this
| part:
|
| > PolyScale automatically and intelligently caches or
| invalidates data close to where it is being requested.
___________________________________________________________________
(page generated 2023-08-24 23:02 UTC)