[HN Gopher] Timescale Announces New Database Cloud
___________________________________________________________________
Timescale Announces New Database Cloud
Author : manigandham
Score : 85 points
Date : 2021-10-05 16:14 UTC (6 hours ago)
(HTM) web link (blog.timescale.com)
(TXT) w3m dump (blog.timescale.com)
| devops000 wrote:
| We have 2 tables that are good candidates for Timescales, others
| are fine with Postgres. We perform joins query across those 2
| table and others. What do you suggest for this? Migrate all to
| timescale or have two database (Timescale for 2 tables and PG for
| the rest) ?
| Croftengea wrote:
| TimescaleDB is a PostgreSQL extension, so you don't have to
| choose. Just convert these two tables to hyper-tables and leave
| the rest as is.
| chrisdalke wrote:
| As far as I know, you can seamlessly join Timescale tables with
| normal Postgres tables in a query. Timescale is activated on a
| per-table basis.
| rgbrgb wrote:
| Looks cool. Will this work with postgraphile, hasura, or prisma?
| They seem to suggest it does but I wonder if anyone has tried it.
| Postgraphile relies on row-level policies [0] and not even all
| hosted postgres instances work with it in that respect.
|
| [0]: https://www.graphile.org/postgraphile/security/
| avthar wrote:
| Generally speaking, if it works with Postgres, it works with
| Timescale. Hasura even has documentation on how to use
| TimescaleDB with Hasura [1].
|
| That said, I'd be curious to hear about other folks
| experiences.
|
| Disclaimer: I work at Timescale.
|
| [1] https://hasura.io/blog/using-timescaledb-with-hasura-
| graphql...
| xbpx wrote:
| Clickhouse went corp a couple weeks ago, Timescale goes fully
| managed, Snowflake, Dremio, DBX ... :popcorn:
|
| Apache Arrow, K8s, ML analytics have given rise to another DB
| War.
|
| The end of NoSQL was the realization that SQL had a good reason
| for existing in most cases. Now we have massively distributed SQL
| in many flavours. I wonder what the hard lessons will be this
| time?
|
| I'll wager small data companies will be spending good money on
| vastly overpowered engines... I wonder what else tho?
| akulkarni wrote:
| Exciting things are happening, but to set the record straight,
| we (Timescale) went "all in" on the cloud over a year ago :-)
|
| [0] https://blog.timescale.com/blog/building-open-source-
| busines...
| eloff wrote:
| This is quite interesting. Some of the features and upcoming
| features look really nice. One-click database forks would be
| really handy. VPC peering is nice, not just for security, but
| also so AWS doesn't fleece you with bandwidth charges ($0.01/GB
| on your side and timescale side in the same AZ, and worse if not.
| For big data systems that can be a lot.)
|
| I wonder how the storage works:
| https://docs.timescale.com/cloud/latest/scaling-a-service/#p...
|
| Seems like to scale it separately it would need to be EBS not
| local instance storage? I wonder if magnetic or SSD? That does
| constrain the performance, especially for queries.
| clarkbw wrote:
| Yes, we use EBS SSD on the backend so we can scale up storage
| separately from the instance. Our Cloud performance metrics are
| based on this backend so the short answer is no it doesn't
| constrain perf. The constraint I see right now is that we are
| currently mostly GP2 with a planned migration to GP3 which will
| allow for new independent controls of IOPS and throughput.
| There are certain, uncommon, situations where customers need to
| bump up performance beyond what the normal GP2 perf steps
| allow.
|
| To tie GP2/3 back into the serverless vs. DBaaS concepts we are
| looking at auto-scale for IOPS/Throughput performance while
| also allowing more direct access such that a customer could
| control performance via APIs to manage on your own.
|
| (timescaler here)
| mfreed wrote:
| And to follow up: Today your IOPS will automatically scale
| with storage, and you can set storage to autoscale with your
| usage. Under the covers, we continually look for ways we can
| optimize that for our users, without them having to think of
| this.
|
| So for most users, they can "set it and forget it" (easy,
| scalable): Launch a default cloud database, which starts out
| small, autoscaling on by default. As they start inserting
| data, the system automatically detects when it starts to
| approach current capacity and automatically increases
| (without any downtime) to more capacity & IOPS.
|
| But for the power user, they have greater control. What that
| means is that you can manually resize, and as mentioned
| above, we'll likely also give you independent control over
| IOPS (independent of capacity). That's the flexibility and
| control we think developers also want...or at least know is
| there is they need it.
|
| (Timescaler & post author)
| akulkarni wrote:
| Sounds like a lot of people don't like the "serverless" term. And
| I agree, it's not great.
|
| So here's an "RFP" - any suggestions for a better term to
| describe this consumption-based experience, where you don't need
| to worry about servers (and ideally, you don't pay for what you
| don't use)?
| beoberha wrote:
| I like "fully managed", but that doesn't go far enough to imply
| the consumption-based model you're getting at.
|
| To me, serverless is fine. Yes, it's a buzzword, but it makes
| sense.
| [deleted]
| tofuahdude wrote:
| > 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.
| leros wrote:
| 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.
| btgeekboy wrote:
| 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.
| qorrect wrote:
| 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 ).
| akulkarni wrote:
| (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_.
| tofuahdude wrote:
| 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.
| bpodgursky wrote:
| I am an engineer and to me "serverless" means I don't pay
| money when I'm not using it. Which I like.
| errwhat wrote:
| I think you still pay with Timescale both in terms of
| committed capacity, and when you pause it, although the
| pitch and docs are all over the shop at the moment.
| zinclozenge wrote:
| I made another comment to this point, but I think you
| described it much more succinctly.
| Scarbutt wrote:
| 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 wrote:
| 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)
| mfreed wrote:
| 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 wrote:
| Doh, guess I should have read the article ;).
| tofuahdude wrote:
| 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.
| ceejayoz wrote:
| "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 wrote:
| If Gay used to mean straight you'd have a point.
| zinclozenge wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-05 23:00 UTC)