Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databricks acquires serverless Postgres vendor bit.io

databricks.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: Databricks acquires serverless Postgres vendor bit.io

#81

Post by kiwicopple »

rovr138 wrote: post #80
CharlesW wrote: post #77

Earlier quoted context omitted.

Supabase is also Postgres-based. https://supabase.com/docs/guides/database/overview

I understand that. But bit.io gave you a postgres database. Supabase gives you a firebase alternative that just happens to be built on top of postgres. - https://supabase.com/docs/guides/getting-started/features - https://docs.bit.io/docs/getting-started

(supabase ceo)

Supabase gives you a full Postgres database, we position ourselves as a Firebase alternative because we offer a few other bells-and-whistles. The database is just postgres[0] and so it has more compatibility than bit.io offered[1]

[0] https://github.com/supabase/postgres

[1] bit.io compatability: https://docs.bit.io/docs/supported-sql

Re: Databricks acquires serverless Postgres vendor bit.io

#82

Post by Scubabear68 »

gdubya wrote: post #54

This is interesting... possibly a move by Databricks to try and build on their "data lakehouse" concept to counter the recent "Fabric platform" announcements at MS Build. Databricks coined the "Delta lake" concept and are still (just about) leading the way, but Fabric has the potential from MS to take away that marketshare. Databricks need to improve their "serverless SQL" offering, and add a serious "data warehouse"…

Of all the stupid tech terms in the world, for some reason “data lakehouse” grates horribly in my head every time I hear it.

Re: Databricks acquires serverless Postgres vendor bit.io

#83

Post by toddmatthews »

candiddevmike wrote: post #7
monero-xmr wrote: post #5

Earlier quoted context omitted.

Assume any acquisition without public terms done over blog post is an acqui-hire. But given the market that's still an accomplishment!

Are there good examples where an acqui-hire works out for the acquiring company? Seems like the acquiring company's culture is almost always at odds with the company being acquired and it causes the high performing teams they paid dearly for to leave. I don't understand what a company hopes to gain doing stuff like this as the (long term) incentives don't seem to align.

if you have a specific task at hand, it may be easier to buy a team that works well with each other and has expertise in a certain area to accomplish a specific task. not expecting them all to stay on forever

Re: Databricks acquires serverless Postgres vendor bit.io

#86

Post by vforgione »

gdubya wrote: post #54

This is interesting... possibly a move by Databricks to try and build on their "data lakehouse" concept to counter the recent "Fabric platform" announcements at MS Build. Databricks coined the "Delta lake" concept and are still (just about) leading the way, but Fabric has the potential from MS to take away that marketshare. Databricks need to improve their "serverless SQL" offering, and add a serious "data warehouse"…

Fabric may eat some of the descriptive analytics portion of Databricks’ lunch, but for core data engineering workflows there is nothing in the Fabric—or Synapse or Power BI—ecosystem that comes close.

There are other fatal flaws to the Spark implementation in Synapse that I think carried over to Fabric. Worst one is the clunkiness/inability to run multiple notebooks concurrently on a cluster.

Re: Databricks acquires serverless Postgres vendor bit.io

#87

Post by lucideer »

codeflo wrote: post #43

I haven't heard of either of those companies. I don't even fully understand what Databricks does. But it's clear that they have no problem shutting down a production database offering with 30 days notice, and have the gall to title this action "Investing in the Developer Experience". If this doesn't send a message that you shouldn't trust them with anything important, I don't know what would.

Slight oversimplification but Apache Spark is basically the "open core" to Databricks' commercial platform.

Re: Databricks acquires serverless Postgres vendor bit.io

#88

Post by rovr138 »

kiwicopple wrote: post #81
rovr138 wrote: post #80

Earlier quoted context omitted.

I understand that. But bit.io gave you a postgres database. Supabase gives you a firebase alternative that just happens to be built on top of postgres. - https://supabase.com/docs/guides/getting-started/features - https://docs.bit.io/docs/getting-started

(supabase ceo) Supabase gives you a full Postgres database, we position ourselves as a Firebase alternative because we offer a few other bells-and-whistles. The database is just postgres[0] and so it has more compatibility than bit.io offered[1] [0] https://github.com/supabase/postgres [1] bit.io compatability: https://docs.bit.io/docs/supported-sql

Just dug more and I see it.

Foranyone looking, their documentation on how to connect, https://supabase.com/docs/guides/database/connecting-to-post...

Re: Databricks acquires serverless Postgres vendor bit.io

#89

Post by tmountain »

coolgoose wrote: post #37

Going to beat a dead horse, but 30 days to migrate your database over ? I hope nobody was seriously using it in production, otherwise it's going to be a fun month for them.

Putting business critical data on a mom and pop service called bit.io was the first mistake.

Re: Databricks acquires serverless Postgres vendor bit.io

#90

Post by jen20 »

ibejoeb wrote: post #39
thewataccount wrote: post #36

Earlier quoted context omitted.

I'm surprised databricks (effectively) is willing to shutter a database service with 1 months notice. What does that say about their own products? What if you integrate their products and are locked to their platform without any easy migration options? If they lose interest on one of their own services, you very well may have 1 month to move, and 2 months to have a chance at keeping your data.

Seriously. Well, I guess their customer roster isn't all that impressive. Sounds like they're willing to burn them.

The problem is the signal it sends to Databricks' other customers about how they will be treated in future.
Post reply on HN