Craig

Craig

@craigkerstiens.com

Product @crunchydata previously MSFT/Citus/Heroku. Talk a lot about Postgres and startups. Why Postgres? https://www.crunchydata.com/why-postgres

3.9K followers258 following495 posts

For the past five years we've focused on production ready Postgres, which is unique from most other database providers. Nothing about that focus changes today, me and the entire team are as laser focused as every on that, but now with an expanded mission of a unified data platform.

We've got food duty at the first kids travel tournament of the year, was thinking about trying to pull off good quality pour over coffee. Anyone have good mechanisms when unclear a good power source for kettle exists?

Way back at Heroku when were having a company onsite... we took the entire company to the SF MOMA for a Dieter Rams exhibit. It wasn't just the designers focused on design it was everyone.

The design of everything from reception to HR to engineering mattered, appreciating and prioritizing design at that level definitely set it apart at a time where that wasn't common.

The details matter. In this case, completely revamping our newsletter signup screen ahead of an upcoming conference. I mean why wouldn't you execute SQL to sign up for a database newsletter?

New release of pg_parquet including: * Amazon S3 * Azure Blob Storage * Google Cloud Storage * http(s) stores * local files Still the easiest way to simplify some of your ETL allowing Postgres and parquet to play well together. www.crunchydata.com/blog/announc...

crunchydata.comAnnouncing pg_parquet v.0.4.0: Google Cloud Storage, https storage, and more | Crunchy Data Blogpg_parquet is a copy/to from for Postgres and Parquet. We're excited to announce integration with Google Cloud storage, https, and additional formats.

Craig reposted

Iceberg has gone from being the thing Netflix (and then Apple) built for their own enormous data lakes to a collaborative open standard where even the competition is learning to co-operate and align: I dug into the Iceberg summit and asked @craigkerstiens.com and others why it's so useful

thestack.technologyThe Iceberg revolution: A catalyst for data transformation?"It took two commands, and it saved us $30,000 a month on our cloud bill"

Updating my nulls today with: \pset null 🤖 Can't decide if it's for R2-D2, C-3PO, or BB-8, but closest I can get for May the 4th. May keep it for a few days...

Craig reposted

Replying to @chris.blue

My guess would be people are just using Iceberg connectors, see things seem to work, and compaction is an after-thought. That's why IMO good Iceberg support is not a connector feature but an engine feature. Like what Crunchy is doing with their DWH, or, for Kafka, Confluent with Tableflow.

A shocking take-away for me from a few weeks ago at Iceberg Summit and similarly at Data Council today is for all those using Iceberg yet so few doing compaction on their data lake files. To me seemed a requirement for any production Iceberg usage, otherwise you wake up shocked in a few months.

In talking with customers that were using CDC tools to get data from Postgres into a data warehouse, 80% of their spend on ETL was the Postgres data movement. Further many of these tools often caused production outages. We knew as soon as we launched Crunchy Data Warehouse we had to solve that.

With yesterdays launch of logical replication for our Data Warehouse. Now you can still use CDC for your other data pipelines, but for your primary Postgres from operational -> analytical that is solved for you–without buying yet another tool.

@andypavlo.bsky.social on HN sums it up well OLAP vs. OLTP isn't right vs. wrong, they're designed for different things. Have a version of this on a slide when explaining Crunchy Data Warehouse and how it's for very different purposes than stock Postgres.

Craig reposted

And there it is: Native logical replication from any Postgres server to Iceberg managed by Crunchy Data Warehouse. Speed up Postgres analytical queries 100x with 2 commands.

Crunchy Data@crunchydata.com

Today we're announcing the availability of logical replication from Postgres to Iceberg with Crunchy Data Warehouse. Now you can seamlessly move data and stream changes from your operational database into an analytical system. www.crunchydata.com/blog/logical...

Craig reposted

Today we're announcing the availability of logical replication from Postgres to Iceberg with Crunchy Data Warehouse. Now you can seamlessly move data and stream changes from your operational database into an analytical system. www.crunchydata.com/blog/logical...

crunchydata.comLogical replication from Postgres to Iceberg | Crunchy Data BlogWe've launched native logical replication from Postgres tables in any Postgres server to Iceberg tables managed by Crunchy Data Warehouse.

Craig reposted

If you're using Postgres for your app data you can stop stitching together a myriad of ETL tools and analytics data stores and use one database for everything. This is both awesome and a lot of fun to use.

Crunchy Data@crunchydata.com

Today we're announcing the availability of logical replication from Postgres to Iceberg with Crunchy Data Warehouse. Now you can seamlessly move data and stream changes from your operational database into an analytical system. www.crunchydata.com/blog/logical...

The way this converges operational and analytical systems is nothing short of magical. bsky.app/profile/crun...

Crunchy Data@crunchydata.com

Today we're announcing the availability of logical replication from Postgres to Iceberg with Crunchy Data Warehouse. Now you can seamlessly move data and stream changes from your operational database into an analytical system. www.crunchydata.com/blog/logical...

🐘 meets 🧊 End to end, under 2 minutes. - Two commands to replicate data from Postgres -> Iceberg - Synced over 10m rows under a minute - Data is continually processed and updated in Iceberg - count(*) in Postgres over 300ms down to under 20ms

I've learned over the years when @louisemeta.bsky.social tells me she has an idea for a blog post I don't hesitate, just simply ask when can I see it because I know it's going to be awesome. This is no exception

Crunchy Data@crunchydata.com

Postgres does a good job of keeping internal statistics of your which are used to plan how queries are executed. But Postgres doesn't always know how columns are related. In this deep dive we look at hacking the statistics for improved performance

This was a lot of fun and covered a ton in 45 minutes. If you watch and have questions happy to setup time to dig in deeper with anyone interested.

Crunchy Data@crunchydata.com

Miss our webinar on running Crunchy Data Warehouse on-premises? We cover an overview, hands on walk through with live querying our data lake to full Iceberg creation, and highlight of popular use cases for it. If you missed it don't worry we got you covered. www.youtube.com/watch?v=Vojg...

View full thread

3. These don't align with where we're headed. Don't capture these. Be straight with customers, don't say "we'll take this into account within planning". This doesn't mean you may not change you're mind and do it in the future, but if it's important it'll come back up.

1. This makes sense and is small, you should just do it. Could be a bug or a feature. Don't put this "into planning to evaluate" just do it. The mental overhead to plan and revisit and get into the to do list makes more work than just doing the thing.

2. This isn't a bad idea, but is a bigger investment. Track this, put it in a queue to evaluate, see how many other customers want this. Put it in your effort vs. impact planning. Some of these you may never do, but still make sense to actually evaluate more deeply of investment relative to impact.

View full thread

- Postgres isn't going away, it's become a standard of databases. - Iceberg is the file format that changes things and turns immutable columnar files into a living database - S3 (or S3 compatible) is the future of storage layers

Postgres will still be a staple for OLTP workloads. It's also a very key piece of the OLAP workloads, but it's one piece of several in a bigger puzzle.

Increasingly these things are being split up into pieces, especially in the case of analytics. You see some of this with some trying to separate compute from storage. This works for Postgres, and is fine, though when you're database is always on with active users you see less benefit.

But, when it comes to analytics even for an always on analytics engine separating these pieces has a much greater impact. In this future world I strongly believe:

Another day another several demos of Crunchy Data Warehouse. The ah-ha moments and lightbulbs that go off for people when I demo this remind me of the early demos of Heroku.