raulb_

Hi there! Developer at Supabase here. I'm happy to finally see live what I've been working on for the last two months. I'm excited to see that Stripe users can finally use Supabase services in a seamless way. For new Supabase users, there is no need to leave the CLI. One command, and you'll have a brand new Supabase account, including a new Supabase resource provisioned just for you. This means that you'll be able to not only use a PG database from the get-go, but it also comes with Storage and Authentication for free. I'm really excited to finally see this project come to light. More to come!

Conduit is an open-source data streaming tool written in Go, and we put it to the test with Kafka Connect in a Postgres to Kafka pipeline. We not only were faster in both CDC and Snapshot, but we also consumed 98% less memory when doing CDC. Here's a blog post about our benchmark so you can try it yourself.

Meroxa improved the Conduit streaming engine by redesigning its architecture, which increased throughput by five times while simplifying the code. The new single-threaded approach processes batches of records, reducing latency and enhancing performance significantly compared to the old system. Testing showed that the new architecture can handle a peak of over 500,000 messages per second, demonstrating its efficiency with various message sizes.

My thoughts are that, while as a developer you could still build up the skills to put them in service with tools such as Terraform (Infrastructure as Code) or any other similar ones, these two serve such different purposes when it comes to scale and maintenance that they still deserve a different skill set. Closing the gap between the two might be possible to start up and run, but not for maintaining or scaling.

Taking a break from things such as social media makes perfect sense since we all need to be encouraged from time to time to stay more connected to our immediate surroundings (including ourselves). However, I do think that the real work comes to find a sustainable balance between anything that could distract us and our values. Overtime, these distractions will become even more prominent and we'd better get used to manage these constantly. To learn say "no" more often, and to be more aware when too much time on certain tools is enough. It's a process and takes time!

Sadly, very true. Only to make the interviewer feel superior on things they have seen multiple times more than anyone else.

I recently felt that way (a year ago), and I felt immensely relieved and excited that I had made that decision. After being comfortable and decently happy in a job, I realised how much I needed to take that step it took me much time to take.

That's a neat use case I hadn't thought about.

I'm on the same boat as you. I occasionally wonder about this when I see people using their working email addresses to commit code, but I personally think that's a hassle I don't want to go through. I get the benefits of those who do it, but I'm ok with exposing my personal email address to other peers (or everybody since most of my work is open source anyways). Maybe, if I ever feel judged by what I do during my working hours or viceversa (something I doubt will ever occur at my current company Meroxa), then it's when I would probably think of setting a different account.