4 ms·

> The future is serverless, but not database-less. I'm a fan of Timescale but definitely not a fan of "serverless" as a phrase. That phrase is just abstractin

> The future is serverless, but not database-less. I'm a fan of Timescale but definitely not a fan of "serverless" as a phrase. That phrase is just abstracting "other people's computers" one additional degree, in a borderline meaningless way. There's still a server. How is that serverless? It's just a server managed in a more indirect way. Please convince me I am wrong here.

qorrect 5y ago
Also a fan and user of Timescale, and I hate the serverless phase. I'm pretty sure everyone is pushing it so they can make money from SaS. But if this allows them to give it away for free, then I'm all for it ( just won't be using it ).
- mfreed 5y ago
  I'm the author of the blog post, and I can also say that I'm not thrilled from the serverless phrase either. It's turtles all the way down =) But for better or worse, it seems like the industry has adopted it. So, we're trying to explain actually how our vision is different. In that we don't want to hide developers completely from their services behind these black-box abstractions. But provide something that's similarly easy and scalable (and automated), but allow developers greater control, flexibility, and understanding when they want it.
  - qorrect 5y ago
    Doh, guess I should have read the article ;).
  - tofuahdude 5y ago
    The best way to be different is to be different. Don't even say serverless at all. You're falling into the trap of being like everyone else.
- akulkarni 5y ago
  (Timescale co-founder) I also used to hate the phrase. But now I get it. And it's not about marketing, but about the idea that the developers _doesn't shouldn't have to worry about the server_. For example, when you run a DB on a classic DBaaS, you have to worry about CPU, memory, storage provisioning. But when you use a classic SaaS service (e.g., Stripe, Twilio), you don't think about servers at all - but rather just how much you are consuming. The Serverless model for databases is aiming to apply a SaaS like experience but for DBaaS. Where you don't need to think about provisioning, but about consumption. What we (try to) do in this article is to push beyond that serverless paradigm. We believe there are real drawbacks to the "serverless black box" architecture that the industry is building, and what (we believe) developers need (including ourselves) is a more a "transparent box." Hope this helps. But "serverless" also feels a little like "horseless carriages". I suspect in 5 years we'll have a better term that describes this concept for what it _is_, not what it _isn't_.
  - Scarbutt 5y ago
    With timescale you still have to deal and think about database connections, nodes and what not. IMO, a truly serverless database is something like dynamodb which just gives you an HTTP endpoint and they take care of the rest.
    - avthar 5y ago
      The point of the blog post is that Timescale cloud isn't totally "serverless", because for some 20% of use cases, you do want to think about nodes and other database internals. From the blog post: "So today’s serverless data platforms are not familiar or flexible. But further, black boxes are never truly easy and worry free: you never know if there are any skeletons lurking in the proverbial closet, just waiting to cause your service to fall over." (Timescale employee here)
  - tofuahdude 5y ago
    FWIW you guys are losing me in your sales pitch here. I am looking for technical products and I interpret "serverless" as marketing garbage, not as "I dont have to worry about the server". Call it managed DB as a service and you're more honest in your product offering. You're suffering marketing-speak in lieu of honesty for a technical product - bad plan, imo.
ceejayoz 5y ago
"Gay people aren't even always happy! Gay means happy!" Language changes. "Serverless" clearly doesn't mean "computers aren't involved", but "the computers are someone else's responsibility". It's a marketing term, just like "cloud", and it's unlikely to go away. As with "hackers vs. crackers", "Linux vs. GNU/Linux", "copyright infringement vs. piracy", and other similar scenarios, the ship has sailed here.
- mrits 5y ago
  If Gay used to mean straight you'd have a point.
zinclozenge 5y ago
Serverless should probably just be re-named to "pay-for-request/cpu time/whatever" or something like that. By and large most if not all "serverless" databases or data services (like kafka/pulsar) are just multi-tenant deployments and you're billed on the metrics your tenant generates. Unlike RDS where you provision an instance that you pay for as long as it's running.
leros 5y ago
I like serverless. I know that cloud providers can run my code and auto scale it however is needed. I don't want to worry about how that actually works. I don't want to auto scale servers or think about RAM, etc. I also like cloud services like Timescale. I just want a database of a certain size. How it runs? I don't care at all as long as it works.
- brodock 5y ago
  > I don't want to worry about how that actually works. The problem is that while you don't want to know you end-up having to. As soon as you hit the limitations you have to workaround it. As soon as what you are doing becomes expensive for reasons you ignored before, you have to go back and rewrite. The only thing is that because it's a Blackbox, you also have to guess and poke it until it does the thing you want.
  - jiggawatts 5y ago
    A fun gotcha like this is that if you write to an S3 bucket fast enough, they auto-upgrade you to a more powerful set of servers... but this incurs a short outage. Unfortunately, this outage will happen exactly when you don't want it to: when the system is busy with a high write volume! You just have to "know" that these things happen, and because it's all serverless, it's essentially invisible and out of your control.
btgeekboy 5y ago
Your view is the pedant’s view. Of course there are servers. There always will be, to some degree. They’re just not your servers to manage (e.g. update, scale) or pay for. You don’t own them, or even rent them, so you can eliminate the hardware details from your thought process.
- tomrod 5y ago
  > Your view is the pedant’s view You still face constraints, and the platform design is informed by the hardware it runs on.

qorrect 5y ago

Also a fan and user of Timescale, and I hate the serverless phase. I'm pretty sure everyone is pushing it so they can make money from SaS. But if this allows them to give it away for free, then I'm all for it ( just won't be using it ).

mfreed 5y ago
I'm the author of the blog post, and I can also say that I'm not thrilled from the serverless phrase either. It's turtles all the way down =) But for better or worse, it seems like the industry has adopted it. So, we're trying to explain actually how our vision is different. In that we don't want to hide developers completely from their services behind these black-box abstractions. But provide something that's similarly easy and scalable (and automated), but allow developers greater control, flexibility, and understanding when they want it.
- qorrect 5y ago
  Doh, guess I should have read the article ;).
- tofuahdude 5y ago
  The best way to be different is to be different. Don't even say serverless at all. You're falling into the trap of being like everyone else.
akulkarni 5y ago
(Timescale co-founder) I also used to hate the phrase. But now I get it. And it's not about marketing, but about the idea that the developers _doesn't shouldn't have to worry about the server_. For example, when you run a DB on a classic DBaaS, you have to worry about CPU, memory, storage provisioning. But when you use a classic SaaS service (e.g., Stripe, Twilio), you don't think about servers at all - but rather just how much you are consuming. The Serverless model for databases is aiming to apply a SaaS like experience but for DBaaS. Where you don't need to think about provisioning, but about consumption. What we (try to) do in this article is to push beyond that serverless paradigm. We believe there are real drawbacks to the "serverless black box" architecture that the industry is building, and what (we believe) developers need (including ourselves) is a more a "transparent box." Hope this helps. But "serverless" also feels a little like "horseless carriages". I suspect in 5 years we'll have a better term that describes this concept for what it _is_, not what it _isn't_.
- Scarbutt 5y ago
  With timescale you still have to deal and think about database connections, nodes and what not. IMO, a truly serverless database is something like dynamodb which just gives you an HTTP endpoint and they take care of the rest.
  - avthar 5y ago
    The point of the blog post is that Timescale cloud isn't totally "serverless", because for some 20% of use cases, you do want to think about nodes and other database internals. From the blog post: "So today’s serverless data platforms are not familiar or flexible. But further, black boxes are never truly easy and worry free: you never know if there are any skeletons lurking in the proverbial closet, just waiting to cause your service to fall over." (Timescale employee here)
- tofuahdude 5y ago
  FWIW you guys are losing me in your sales pitch here. I am looking for technical products and I interpret "serverless" as marketing garbage, not as "I dont have to worry about the server". Call it managed DB as a service and you're more honest in your product offering. You're suffering marketing-speak in lieu of honesty for a technical product - bad plan, imo.

ceejayoz 5y ago

"Gay people aren't even always happy! Gay means happy!" Language changes. "Serverless" clearly doesn't mean "computers aren't involved", but "the computers are someone else's responsibility". It's a marketing term, just like "cloud", and it's unlikely to go away. As with "hackers vs. crackers", "Linux vs. GNU/Linux", "copyright infringement vs. piracy", and other similar scenarios, the ship has sailed here.

mrits 5y ago
If Gay used to mean straight you'd have a point.

zinclozenge 5y ago

Serverless should probably just be re-named to "pay-for-request/cpu time/whatever" or something like that. By and large most if not all "serverless" databases or data services (like kafka/pulsar) are just multi-tenant deployments and you're billed on the metrics your tenant generates. Unlike RDS where you provision an instance that you pay for as long as it's running.

leros 5y ago

I like serverless. I know that cloud providers can run my code and auto scale it however is needed. I don't want to worry about how that actually works. I don't want to auto scale servers or think about RAM, etc. I also like cloud services like Timescale. I just want a database of a certain size. How it runs? I don't care at all as long as it works.

brodock 5y ago
> I don't want to worry about how that actually works. The problem is that while you don't want to know you end-up having to. As soon as you hit the limitations you have to workaround it. As soon as what you are doing becomes expensive for reasons you ignored before, you have to go back and rewrite. The only thing is that because it's a Blackbox, you also have to guess and poke it until it does the thing you want.
- jiggawatts 5y ago
  A fun gotcha like this is that if you write to an S3 bucket fast enough, they auto-upgrade you to a more powerful set of servers... but this incurs a short outage. Unfortunately, this outage will happen exactly when you don't want it to: when the system is busy with a high write volume! You just have to "know" that these things happen, and because it's all serverless, it's essentially invisible and out of your control.

btgeekboy 5y ago

Your view is the pedant’s view. Of course there are servers. There always will be, to some degree. They’re just not your servers to manage (e.g. update, scale) or pay for. You don’t own them, or even rent them, so you can eliminate the hardware details from your thought process.

tomrod 5y ago
> Your view is the pedant’s view You still face constraints, and the platform design is informed by the hardware it runs on.