Five years ago I joined @crunchydata.com, shortly after I wrote about having unfinished business with Postgres. Today as part of Snowflake that journey is continuing. We've built some amazing things, but are just getting started. www.crunchydata.com/blog/crunchy...

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.

Production ready Postgres. That's it.

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...

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

Happy revenge of the sith day to all who celebrate.

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...

A few weeks in, but still every time I demo this it feels absolutely magical. Finally convergence of transactional and analytical data. www.crunchydata.com/blog/logical...

Now live on the Crunchy Bridge dashboard the ability to seamlessly sync data between your operational database over to your data warehouse for analytics - docs.crunchybridge.com/changelog#da...

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.

Yesterday met someone at Data Council that was very familiar with @crunchydata.com team and described us as basically being team Avengers for Postgres/databases. That's a new one, but will totally take it.

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.

Sitting in Ryan Blue’s talk at Data Council and about to leave from Q&A to head to office hours and question comes up about CDC from databases to Iceberg… @marcoslot.com makes a hard U-turn to tune in

@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.

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.

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...

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.

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

🐘 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

Now playing: Eye of the tiger

We now expose the physical zone directly to users on Crunchy Bridge. Most think they know what an availability zone is, but did you know by default AWS randomizes the names between accounts. You have to get to the physical zone id to colocate things - docs.crunchybridge.com/changelog#fe...

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

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.

There are 3 types of customer feedback you can get:

What's this? Flexible/variable long term backup retention 👀

Databases are changing, things are evolving, historically your database was the storage format, storage engine, and the querying engine.

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.

Great talk from @marcoslot.com at recent Iceberg meetup on building a Postgres Data Warehouse with Iceberg! www.youtube.com/watch?v=cEnq...

Within Crunchy Data Warehouse we have a lot of new flexibility in how you work with your database. First, you have standard Postgres heap tables.

When people keep replying all but it's a text thread 🤦‍♂️

Great post from @simpsoka.bsky.social on what she calls "papercuts" - kathykorevec.substack.com/p/papercuts-...

If you want to be really good at databases, don't start with learning SQL, start with relational algebra and relational calculus. I know it sounds crazy, but once you get that the rest of SQL comes so shockingly easy. Completely changes how you think about data.

How many people use window functions in Postgres? It's one of those features that when you need them they're perfect, letting you compare between previous or future records or organize across records, but I always find it difficult to describe them to folks. How would you explain window functions?

It's increasing to almost half the time @gerikerstiens.bsky.social comes down the stairs in an outfit that matches mine (to be clear I was dressed well before her) and today it's matching softball team shirts

When we first launched Crunchy Data Warehouse the thing that surprised me most was how many wanted to self-manage on-premises. Took us a few months, but here it is.

Have you setup a psqlrc file? It's like bashrc but for psql within Postgres. Some handy things in mine: \x auto \timing \pset null 👻

I've encountered a database without constraints that "enforces them within the app" I've encountered data quality issues. Postgres has a variety of constraints to help, not just primary/unique and foreign keys, but also not null and check constraints.

We weren't really thinking of log management as a target use case, but Iceberg is ideal as the final destination for logs, and having transactions & built-in job scheduling & a fast query engine (& laser focus on developer experience) makes things really simple and cost-effective.

Something I've always found pride in is making developer tooling more accessible. You won't find many that think Postgres isn't powerful, but navigating it can be overwhelming. Scheduled jobs in a database aren't a "new thing", pg_cron has long been around but it wasn't always "friendly".

I got a number of questions on how we saved $30k a month on cloudwatch by moving logs directly to S3/Iceberg with Postgres so I wrote up how in a bit more detail - www.crunchydata.com/blog/reducin...

We talk with users every week about whether Citus is a good fit for them. While Citus is a very powerful Postgres extension it has very specific use cases where it does fit, here we break down the cases where Citus is a fit as well as when it's not -

Partitioning in Postgres is great if you've got any form of time series data. It can allow higher ingest, faster queries, and easily archiving old data. Common examples could be: - logs - events - metrics

I'm not throwing shade at Citus. It was and still is some amazing engineering. You just probably don't need it, in most cases just use Postgres without Citus. www.crunchydata.com/blog/citus-t...

Just gave a demo of Crunchy Data Warehouse, they're currently already running Iceberg running Spark and several other things for their pipeline. They asked about compaction walked them through - www.crunchydata.com/blog/automat... "So we don't have to deal with all the complexity we've built"? Yup!

When's the last time you checked in on how your queries were performing? If you can't remember now is a great time to check in with pg_stat_statements: SELECT total_exec_time, mean_exec_time as avg_ms, calls, query FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;

Looks like I’m ended March with a lovely ski glass sunburn/tan

Can you guess when we moved internal logging from cloudwatch over to S3/Iceberg via Crunchy Data Warehouse?