DEV Community: Gaspard Boursin

Announcing Meteroid OSS v1 RC and Cloud 🦀

Gaspard Boursin — Thu, 29 Jan 2026 10:13:11 +0000

Hey dev.to! 👋

Two years ago, we wrote the first line of code for Meteroid. Today, we're launching our hosted cloud platform and releasing our open-source v1 release candidate — and we're doing it on Product Hunt.

We'd love your support, but first, let me tell you why we built this thing.

The Problem We Kept Running Into

If you've ever tried to implement anything beyond basic subscriptions, you know the pain:

Stripe Billing takes ~0.8% on top of payment fees, checkout fees, invoice fees, tax fees, revenue analytics fees etc, and gets complicated fast when you need usage-based pricing or some flexibility in your plans
Specialized billing platforms want 5-figure annual contracts before you've even validated your pricing model
Building it yourself means months of engineering time on invoice edge cases instead of your actual product

We got frustrated enough to do something about it.

What We Built

Meteroid is an open-source monetization platform. Not "open-core" with all the good stuff behind a paywall like most our competitors — actually open-source.

One platform for:

📦 Subscription management (the basics, done right)
📊 Usage-based billing & metering (send events, we handle the math)
🧾 Invoicing (automated, accurate, on-time)
💼 Quote-to-cash / CPQ (for when sales closes custom deals)
📈 Revenue insights (actual business intelligence to act on signals, our main goal for 2026)

For the devs wondering about the stack:

Backend in Rust 🦀 (speed, safety, and it handles millions of usage events without breaking a sweat)
React frontend
PostgreSQL for transactional data
ClickHouse for analytics
Kafka for event streaming

We're not slapping a UI on Stripe. This is infrastructure built from the ground up for modern SaaS pricing models.

The "Visionary" Plan — Our Launch Offer for founders

We created the Visionary plan: €49/month for the full platform — billing, metering, invoicing, insights, everything — until you hit €1M in cumulative revenue billed through Meteroid.

No percentage cuts. No "talk to sales" gatekeeping. No bait-and-switch.

Why? Because we are early-stage founders too. Advanced billing shouldn't be something you "graduate into" at Series B. You should be able to experiment with usage-based pricing, hybrid models, and custom deals from day one.

Why Open Source Matters Here

Billing is core infrastructure. It touches your revenue, your customers, your contracts. We think you should be able to:

Inspect it — see exactly how your invoices are calculated
Extend it — add custom integrations without waiting on our roadmap
Self-host it — if that's what you need (Docker Compose and Helm charts included)
Trust it — no vendor lock-in, no surprises

We're building in public. Our GitHub repo has been open since day one. And we're not going anywhere !

What We're NOT Doing

A few conscious choices:

❌ No giant sales team — we're mostly self-serve, so we can focus on building
❌ No feature-gating — the Visionary plan includes everything, not a crippled "starter" tier
❌ No fake "open source" — we're AGPL, not open-core with all the features behind enterprise licenses

We do offer sponsored development — if you need a specific integration or feature fast, you can fund it and it goes into the open-source codebase. Everyone benefits.

We're Live on Product Hunt 🚀

We're live today !

If Meteroid sounds like something you'd use — or something you wish existed when you were building your billing system at 2am — we'd really appreciate your feedback and support:

👉 Support us on Product Hunt

Try It Out

🌐 Cloud: app.meteroid.com — sign up, play with the sandbox
📖 Docs: docs.meteroid.com
⭐ GitHub: github.com/meteroid-oss/meteroid
💬 Discord: Join our community

We'd love to hear what you think. Drop a comment, roast our landing page, tell us what features you need — we're listening.

Thanks for reading, and thanks for building with us. 🙏

— Gaspard, Donatien & the Meteroid team

Anthropic just acquired Bun.js. Here's why.

Gaspard Boursin — Wed, 03 Dec 2025 13:49:49 +0000

Anthropic just acquired Bun. First acquisition ever for the company behind Claude and Claude Code.

Most takes I've seen focus on speed. "Claude Code needs fast tooling." "Milliseconds matter at scale." That's not wrong, but it's not the interesting part either.

The interesting part is what this signals about where AI development is headed.

Let's dive in!

First, some context

Bun is a JavaScript runtime that's faster than Node.js. It's also a package manager, bundler, and test runner, all in one. It's open source, MIT-licensed, and has about 7 million monthly downloads.

Anthropic makes Claude. Their coding tool, Claude Code, has been growing fast: it hit $1 billion in annual run-rate revenue six months after public launch. That's not a typo. Six months.

Here's the connection: Claude Code ships as a Bun executable. When you install Claude Code, you're running Bun. This isn't a loose partnership but a dependency.

Why Anthropic needed to own this

Here's how developer tooling has evolved in the AI era:

Phase 1:
LLMs generate code, humans run it. ChatGPT writes, you copy-paste, you fix.
Phase 2:
LLMs call tools via function calling and MCPs. Still orchestrated, constrained, pre-defined.
Next - Phase 3:
Agents that write new tools and interactive interfaces on the fly, compile them, execute them, observe results, iterate. Spawn sub-agents and processes. Orchestrate parallel workloads.

If Phase 3 is coming—and Anthropic clearly believes it is—then the runtime isn't just where code executes. It's (literally for once) the operating system for AI agents. You want to own that.

The practical angle matters too. Bun compiles projects into single-file executables. No Node install, no dependency hell, just a binary. That's how Claude Code ships cleanly to millions of machines, and how agents could eventually distribute tools to each other.

What about OpenAI? Both companies have consumer products and APIs, but their acquisition patterns reveal priorities. OpenAI just acquired Sky (NL on MacOS) and invested in consumer-facing features.
Anthropic's first acquisition is a JavaScript runtime. They're betting that the winning AI company will be the one most deeply embedded in how software gets built, not the one with the best chat UI.

Jarred Sumner (Bun's founder) seems to agree. After walking through the acquisition with Anthropic's competitors, his conclusion: "I think Anthropic is going to win." That's not PR. That's someone betting his life's work on a conviction.

We're building Meteroid, a fully open-source billing platform for SaaS.

If you have a minute, please give us a star on Github! ⭐️

This would help us a lot ❤️

For JS developers: This is probably good

Bun had $26M in funding, zero revenue, and "eventually we'll build a cloud hosting product" as the monetization plan. That's the standard dev tools playbook, and it usually ends one of three ways: awkward pricing, acquisition for talent, or slow death.

Now Bun has a different mandate: be the best runtime for Anthropic's needs, which happen to overlap heavily with being the best runtime period.

The good news: If sustainability worried you (VC-funded, zero revenue, unclear business model) that's resolved. Anthropic's flagship product depends on Bun. They're not letting it rot.

The risk shifts, not disappears. Bun's roadmap now has a $1B ARR product as its primary stakeholder. That's probably fine; Claude Code needs speed, stability, and Node compatibility, which is what everyone wants. But it's worth watching:

Does Node.js compatibility keep improving?
Do agent-specific optimizations start crowding out general features?
Does GitHub issue responsiveness stay high?

My take: This is likely net positive. The incentives align more than they conflict. Check back in 18 months.

TL;DR

The real reason isn't speed. It's distribution (single-file executables), dependency control (they already relied on Bun), and positioning for a future where agents are the primary users of developer tooling.
We're moving from "LLMs that generate code" to "agents that build and run their own tools." The runtime becomes the agent's operating system. Anthropic wants to own that.
For JS devs: Sustainability concern addressed. New concern: priority alignment. Watch Node.js compatibility and community responsiveness.
The meta-story: Anthropic is betting on developer infrastructure, not consumer AI. This won't be their last acquisition like this.

The most active contributor to Bun is already an AI agent. That's not the future. That's now.

I hope you enjoyed this read ! (and the handmade cover picture 🙈)

If you found it insightful, you can support us by leaving Meteroid a star on Github ⭐️!

Cheers !

What's coming to PostgreSQL ? 🐘

Gaspard Boursin — Tue, 30 Apr 2024 15:03:16 +0000

PostgreSQL, the powerful, reliable and highly extensible open-source relational DBMS, has been a mainstay in the database world for over three decades, gaining a loyal following among developers and organizations alike, for an ever-growing number of use case.

In the past couple years, amidst the increasing importance of "global-scale" P/IaaS like Vercel and Cloudflare, many MySQL or SQLite-based solutions like Planetscale, Turso, and Cloudflare D1 have been making waves with their serverless architecture, global redundancy promises, unlimited storage and easy scalability.

At the same time, PostgreSQL is undergoing a series of transformations that could redefine its role in the database landscape.
In this article, we'll explore some of the exciting developments shaping the future of PostgreSQL, with a focus on the contributions of companies like Supabase, Neon, ParadeDB or AWS.

Separation of Compute and Storage

One of the most significant advancements coming to the PostgreSQL ecosystem lies in the separation of compute and storage. Companies like Neon, AWS, and recently Supabase are pioneering this approach, which brings major benefits:

Horizontal Scalability: Just add more compute nodes to allow the system to handle increased load without hitting performance walls.
Cost-Effective Scaling: The separation allows for independent scaling of compute and storage resources based on specific workload requirements, optimizing costs and possibly offloading storage to S3.
Seamless Replication and High Availability: The decoupled architecture simplifies replication and enables high availability setups.
Branching and Improved Developer Experience: The storage layer can be easily forked and attached to new compute instances, facilitating branching and enhancing the development workflow.

For a deeper dive into the benefits and implications of this architecture, I recommend exploring this insightful blog post from David Gomes and the linked resources.

Neon is already offering a production-ready postgres serverless offering using this technology, all open source, jump to their hello-world post for an overview of their approach.

Pluggable Storage and Improved Table Engines

At the heart of every database lies its table engine.
In Postgres 12, a basic support for a "Pluggable Storage" was introduced, as a way to define different table engines for different tables in the same database.

This unlocks the potential to use a single PostgreSQL instance for various use cases, from OLAP and AI vector search to log search, without compromising performance or storage efficiency.

However the initial implementation had limitations, stalled and didn't fully achieve its goals.

Some solutions like CitusData's columnar storage leveraged this initial API but came with significant restrictions over core PostgreSQL features.

Enter Oriole.
Acquired by Supabase officially in April 2024, Oriole is designed as a drop-in replacement for the existing storage engine, bringing notable performance improvements and advanced features. It reduces I/O (enabling decoupled storage and compute), supports page-level data compression, and introduces index-organized tables.

create extension orioledb; -- enable the extension

create table posts (
  id int8 not null,
  title text not null,
  body text not null,
  primary key (id)
) using orioledb;    -- Specify the storage format

The Oriole team is actively driving contributions around Pluggable Storage, building upon the efforts initiated in PostgreSQL 12 to create a more integrated extension ecosystem, supporting many more advanced extensions and use cases on standard PostgreSQL instances.

A few words about us

Our project, Meteroid, is a modern and open-source billing platform that focuses on business intelligence and actionable insights.

To allow our users to self-host without our complete saas-focused infrastructure, including a Clickhouse cluster, we've been researching options to leverage Postgres more intensively for all our different use cases. We figured we would share some of our findings about the ecosystem through this blog post.

If you have a minute, please consider starring us on Github ⭐️ ! This would help us a lot ❤️

Extending PostgreSQL: OLAP, AI, Search, and Beyond

The PostgreSQL extension ecosystem has seen remarkable achievements lately. Two notable examples are:

pgvector: This community-driven effort provides a vector data type and search functionality for high-dimensional vectors. Despite its relatively small codebase, pgvector rivals the performance of many specialized vector databases.
ParadeDB: Implemented in Rust, this open-source PostgreSQL extension(s) delivers outstanding results in both OLAP (closing the gap with ClickHouse) and Search (outperforming Elasticsearch in some benchmarks) use cases.

With the new Pluggable Storage model, these extensions and many others could be easily added to any PostgreSQL instance, potentially even interacting with each other, unlocking powerful combinations and enabling PostgreSQL to handle a wide range of workloads efficiently.

Many other projects exist around the postgres community, to cover emerging use cases. A couple examples :

electric-sql (the people behind CRDTs) is building a sync layer between postgres and local/embeded SQLite database to build local-first apps, a paradigm shift toward dynamic and instant local apps
AWS RDS team created Trusted Language Extensions (pg_tle), an initiative to make postgres extensions more accessible to users relying on a cloud managed database. This is a pretty huge step for the open-source/self-hosted community, as until then building on top of an extension could make the deployment a lot more complex.

A couple of resources to delve deeper

Scaling Postgres, a youtube podcast from Creston Jamison with a lot of discussions and news curation across the postgres ecosystem
pg is eating the db world from @fengruohang , an extensive blog post to understand the unique position of Postgres in the ecosystem

The Future may be both Unified and Distributed

As applications become increasingly global and complex, the need for a distributed, multi-purpose database is more pressing than ever.

The incredibly extensible core of Postgres, alongside the massive community and shared efforts from many players across the industry, has led to impressive advancements. From the separation of compute and storage to a new Pluggable Storage, and the growing number of highly powerful extensions across languages and domains, Postgres is poised as a strong contender for a global, holistic database solution, to meet the demands of modern software development.

The future of PostgreSQL may not just be about being a reliable and feature-rich database, but about becoming a catalyst for building applications that are fast, scalable, and adaptable to the ever-changing needs of businesses and users.

I hope you enjoyed this read ! If you found it helpful, don't forget to give our repo a star! Your support means the world to us.

⭐️ Star Meteroid ⭐️

Cheers !

What we learned building our SaaS with Rust 🦀

Gaspard Boursin — Mon, 29 Apr 2024 10:45:02 +0000

In this post we will not answer the question everybody asks when starting a new project: Should I do it in Rust ?

Instead, we'll explore the pitfalls and insights we encountered after confidently answering "absolutely!" and embarking on our journey to build a business using mostly Rust.

This post aims to provide a high-level overview of our experiences, we will delve deeper into the details in an upcoming series.

(vote in the comments for our next post 🗳️)

Why Rust

Choosing the right language for a project is never a one-size-fits-all decision.

A couple words about our team and use case :

we're a team of 6, with almost no prior Rust experience but an extensive Scala/Java background building data-intensive applications
our SaaS is a Billing platform with a strong focus on analytics, realtime data and actionable insights (think Stripe Billing meets Profitwell, with a dash of Posthog).
our backend is fully in Rust (divided in 2 modules and a couple of workers), and talks to our React frontend using gRPC-web

We're open source !
You can find our repo here : https://github.com/meteroid-oss/meteroid
We would love your support ⭐ and contribution

We therefore have some non-negotiable requirements that happen to fit Rust pretty well: performance, safety, and concurrency.
Rust virtually eliminate entire classes of bugs and CVEs related to memory management, while its concurrency primitives are pretty appealing (and didn't disappoint).

In a SaaS, all these features are particularly valuable when dealing with sensitive or critical tasks, like in our case metering, invoice computation and delivery.

Its significant memory usage reduction is also a major bonus to build a scalable and sustainable platform, as many large players including Microsoft have recently acknowledged.

Coming from the drama-heavy and sometimes toxic Scala community, the welcoming and inclusive Rust ecosystem was also a significant draw, providing motivation to explore this new territory.

With these high hopes, let's start our journey !

Lesson 1: The Learning Curve is real

Learning Rust isn't like picking up just another language. Concepts like ownership, borrowing, and lifetimes can be daunting initially, making otherwise trivial code extremely time consuming.

As pleasant as the ecosystem is (more on that later), you WILL inevitably need to write lower-level code at times.

For instance, consider a rather basic middleware for our API (Tonic/Tower) that simply reports the compute duration :

impl<S, ReqBody, ResBody> Service<Request<ReqBody>> for MetricService<S>
where
    S: Service<Request<ReqBody>, Response = Response<ResBody>, Error = BoxError>
        + Clone + Send + 'static,
    S::Future: Send + 'static,
    ReqBody: Send,
{
    type Response = S::Response;
    type Error = BoxError;
    type Future = ResponseFuture<S::Future>;

    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
        self.inner.poll_ready(cx)
    }

    fn call(&mut self, request: Request<ReqBody>) -> Self::Future {
        let clone = self.inner.clone();
        let mut inner = std::mem::replace(&mut self.inner, clone);
        let started_at = std::time::Instant::now();
        let sm = GrpcServiceMethod::extract(request.uri());

        let future = inner.call(request);

        ResponseFuture {
            future,
            started_at,
            sm,
        }
    }
}

#[pin_project]
pub struct ResponseFuture<F> {
    #[pin]
    future: F,
    started_at: Instant,
    sm: GrpcServiceMethod,
}

impl<F, ResBody> Future for ResponseFuture<F>
where
    F: Future<Output = Result<Response<ResBody>, BoxError>>,
{
    type Output = Result<Response<ResBody>, BoxError>;

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        let this = self.project();
        let res = ready!(this.future.poll(cx));
        let finished_at = Instant::now();
        let delta = finished_at.duration_since(*this.started_at).as_millis();
        // this is the actual logic
        let (res, grpc_status_code) = (...) 

        crate::metric::record_call(
            GrpcKind::SERVER,
            this.sm.clone(),
            grpc_status_code,
            delta as u64,
        );

        Poll::Ready(res)
    }
}

Yes, in addition to generic types, generic lifetimes, and trait constraints, you end up writing a custom Future implementation for a simple service middleware.
Keep in mind that this is a somewhat extreme example, to showcase the rough edges existing in the ecosystem. In many cases, Rust can end up being as compact as any other modern language.

The learning curve can vary depending on your background. If you're used to the JVM handling the heavy lifting and working with a more mature, extensive ecosystem like we were, it might take a bit more effort to understand Rust's unique concepts and paradigms.

However, once you grasp these concepts and primitives, they become incredibly powerful tools in your arsenal, boosting your productivity even if you occasionally need to write some boilerplate or macros.
It's worth mentioning that Google has successfully transitioned teams from Go and C++ to Rust in a rather short timeframe and with positive outcomes.

To smooth out the learning curve, consider the following:

Read the official Rust Book cover to cover. Don't skip chapters. Understanding these complex concepts will become much easier.
Practice, practice, practice! Work through Rustlings exercises to build muscle memory and adopt the Rust mindset.
Engage with the Rust community. They're an incredible bunch, always willing to lend a helping hand.
Leverage GitHub's search capabilities to find and learn from other projects. The ecosystem is still evolving, and collaborating with others is essential (just be mindful of licenses and always contribute back). We'll explore some of the projects we've been inspired by in the next post.

Lesson 2: The ecosystem is still maturing

The low-level ecosystem in Rust is truly incredible, with exceptionally well-designed and maintained libraries that are widely adopted by the community. These libraries form a solid foundation for building high-performance and reliable systems.

However, as you move higher up the stack, things can get slightly more complex.

For example, in the database ecosystem, while excellent libraries like sqlx and diesel exist for relational databases, the story is more complicated with many asynchronous or non-relational database clients. High-quality libraries in these areas, even if used by large companies, often have single maintainers, leading to slower development and potential maintenance risks.
The challenge is more pronounced for distributed systems primitives, where you may need to implement your own solutions.

This is not unique to Rust, but we found ourselves in this situation quite often compared to older/more mature languages.

On the bright side, Rust's ecosystem is impressively responsive to security issues, with swift patches promptly propagated, ensuring the stability and security of your applications.

The tooling around Rust development has been pretty amazing so far as well.

We'll take a deep dive into the libraries we chose and the decisions we made in a future post.

The ecosystem is constantly evolving, with the community actively working to fill gaps and provide robust solutions. Be prepared to navigate uncharted waters, allocate resources accordingly to help with maintenance, and contribute back to the community.

...did I mention we are open source ?

Meteroid is a modern, open-source billing platform that focuses on business intelligence and actionable insights.

We need your help ! If you have a minute,

Your support means a lot to us ❤️
⭐️ Star us on Github ⭐️

Lesson 3: Documentation Lies in the Code

When diving into Rust's ecosystem, you'll quickly realize that documentation sites can be a bit... well, sparse, at times.
But fear not! The real treasure often lies within the source code.

Many libraries have exceptionally well-documented methods with comprehensive examples nestled within the code comments. When in doubt, dive into the source code and explore. You'll often discover the answers you seek and gain a deeper understanding of the library's inner workings.

While external documentation with usage guides is still important and can save developers time and frustration, in the Rust ecosystem, it's crucial to be prepared to dig into the code when necessary.

Sites like docs.rs provide easy access to code-based documentation for public Rust crates. Alternatively, you can generate documentation for all your dependencies locally using cargo doc. This approach might be confusing at first, but spending some time learning how to navigate this system can be quite powerful in the long run.

Needless to say, another helpful technique is to look for examples (most libraries have an /examples folder in their repository) and other projects that use the library you're interested in, and engage with these communities. These always provide valuable guidance into how the library is meant to be used and can serve as a starting point for your own implementation.

Lesson 4: Don't aim for perfection

When starting with Rust, it's tempting to strive for the most idiomatic and performant code possible.
However, most of the time, it's okay to make trade-offs in the name of simplicity and productivity.

For instance, using clone() or Arc to share data between threads might not be the most memory-efficient approach, but it can greatly simplify your code and improve readability. As long as you're conscious of the performance implications and make informed decisions, prioritizing simplicity is perfectly acceptable.

Remember, premature optimization is the root of all evil. Focus on writing clean, maintainable code first, and optimize later when necessary. Don't try to micro-optimize ¹ (until you really need to). Rust's strong type system and ownership model already provide a solid foundation for writing efficient and safe code.

When optimizing performance becomes necessary, focus on the critical path and use profiling tools like perf and flamegraph to identify the real performance hotspots in your code. For a comprehensive overview of the tools and techniques, I can recommend The Rust Performance Book.

¹ this applies throughout your startup journey, including fundraising

Lesson 5: Errors can be nice after all

Rust's error handling is quite elegant, with the Result type and the ? operator encouraging explicit error handling and propagation. However, it's not just about handling errors; it's also about providing clean and informative error messages with traceable stack traces.
Without tons of boilerplate to convert between error types.

Libraries like thiserror, anyhow or snafu are invaluable for this purpose. We decided to go with thiserror, which simplifies the creation of custom error types with informative error messages.

In most Rust use cases, you don't care that much about the underlying error type stack trace, and prefer to map it directly to an informative typed error within your domain.

#[derive(Debug, Error)]
pub enum WebhookError {
    #[error("error comparing signatures")]
    SignatureComparisonFailed,
    #[error("error parsing timestamp")]
    BadHeader(#[from] ParseIntError),
    #[error("error comparing timestamps - over tolerance.")]
    BadTimestamp(i64),
    #[error("error parsing event object")]
    ParseFailed(#[from] serde_json::Error),
    #[error("error communicating with client : {0}")]
    ClientError(String),
}

Investing time in crafting clean and informative error messages greatly enhances the developer experience and simplifies debugging. It's a small effort that yields significant long-term benefits.

However sometimes, even more in SaaS use cases where logs stays outside of the user scope, it makes a lot of sense to keep the full error chain, with possibly additional context along the way.

We're currently experimenting with error-stack, a library maintained by hash.dev that allows exactly that, attaching additional context and keep it throughout your error tree. It works great as a layer on top of thiserror.

It provides an idiomatic API, actualling wrapping the error type in a Report datastructure that keeps a stack of all the errors, causes and any additional context you may have added, providing a lot of informations in case of failure.

We've encountered a couple of hiccups, but this post is far too long already, more on that in a subsequent post !

Wrapping up

Building our SaaS with Rust has been (and still is) a journey. A long, challenging journey at start, but also a pretty fun and rewarding one.

Would we have built our product faster with Scala ?
Certainly.
Would it be as effective ?
Maybe.
Would we still be as passionate and excited as we are today?
Probably not.

Rust has pushed us to think differently about our code, to embrace new paradigms, and to constantly strive for improvement.
Sure, Rust has its rough edges. The learning curve can be steep, and the ecosystem is still evolving. But that's part of the excitement.
Beyond the technical aspects, the Rust community has been an absolute delight. The welcoming atmosphere, the willingness to help, and the shared enthusiasm for the language have made this journey all the more enjoyable.

So, if you have the time and the inclination to explore a new and thriving ecosystem, if you're willing to embrace the challenges and learn from them, and if you have a need for performance, safety, and concurrency, then Rust might just be the language for you.

As for us, we're excited to continue building our SaaS with Rust, to keep learning and growing, and to see where this journey takes us. Stay tuned for more in-depth posts, or vote for which one we should do next in the first comment.

And if you enjoyed this post and found it helpful, don't forget to give our repo a star! Your support means the world to us.

⭐️ Star Meteroid ⭐️

Until next time, happy coding !