We (Basekick Labs) we are the new maintainers of Liftbridge. It went dormant in 2022, and we're reviving it.
Liftbridge adds Kafka-style durability to NATS: commit log, partitions, ISR replication. Single Go binary, no JVM or ZooKeeper.
Architecture: Raft for metadata consensus, ISR (like Kafka) for data replication. Memory-mapped segment files with offset/timestamp indexes.
We're using it for Industrial IoT (streaming layer for Arc, our time-series database), but it works standalone.
Roadmap: Go 1.25+, dependency updates, security audit, CI/CD fixes (Done) and we fixed a few panic errors / race conditions bugs. First release mid January 2026.
Today, the results are in, Arc is now the fastest time-series database on ClickBench, outperforming QuestDB and TimescaleDB across nearly every hardware configuration. It also ranks among the top 5 fastest systems overall, alongside DuckDB, ClickHouse, and Salesforce Hyper.
Arc ingests 2.42 million records per second, tops the Cold Run charts for all system sizes, and does it all in roughly 5,500 lines of code.
It’s built on DuckDB for SQL, MessagePack for ingestion, Parquet + Arrow for columnar storage, and a lock-free multi-threaded core for compaction and WAL.
Benchmarks aren’t everything—I agree—but performance matters. It’s what lets smaller infrastructure handle serious workloads without ballooning costs.
This enables massive IoT ingestion, real-time logistics tracking, aerospace telemetry, observability at scale, and market data analytics—all without a huge footprint.
13 days since launch: 252 GitHub stars, 100+ community conversations shaping the roadmap.
That’s fair, the number alone doesn’t mean much without context.
The benchmark measures fully written time-series records, not bytes. Each record typically includes 1–4 fields, tags, and timestamps, similar to InfluxDB’s Line Protocol structure.
For comparison, the same hardware (AWS c6a.4xlarge) handles around 240K RPS using Line Protocol, while Arc reaches 1.88M RPS with MessagePack, about 7.8× faster on ingestion throughput.
You can see the full ClickBench and ingestion benchmarks are in the repo.
TL;DR: Arc’s strength isn’t massive single records, it’s sustained high-throughput ingestion of structured time-series data while still staying analytical-query friendly.
Schema inference: yes, Arc infers the schema automatically from incoming data (both for MessagePack and Line Protocol). Each measurement becomes a table, and fields/tags map to columns.
Schema evolution: supported. New fields can appear at any time, they’re added to the Parquet schema automatically without migration or downtime.
Custom partitions: currently partitioning is time-based (hour-level by default), but custom partitioning by tag or host or whatever is planned. The idea is to allow you to group by any tag (e.g. device, region) in the storage path for large-scale IoT data.
Roadmap: absolutely. Grafana data source, Prometheus remote write, retention policies, gRPC streaming, and distributed query execution are all in the works.
We are going to start to blogging about it, so, stay tune.
Would love any feedback on what you’d prioritize or what would make adoption easier for your use case.
I’d say both roles are possible, though the original intent of Arc was indeed to act as an offload / long-term store for systems like TimescaleDB, InfluxDB, Kafka, etc. The idea: you send data into Arc to reduce storage and query load on your primary database for ML, deep analysis, etc.
But as we built it, we discovered that Arc is really good not just at storage but at actively answering queries, so it’s kind of hybrid: somewhat “warehouse-like,” but still retaining database qualities in performance. I feel that saying a database its too much, but we are going on that direction.
IoT is absolutely one of the core use cases. You’re often ingesting tens or hundreds of thousands of events per second from edge devices, and you need a system that doesn’t choke. Our binary MessagePack ingestion helps shrink the payload size and reduce parsing overhead, that allows higher throughput for writes, which is crucial in IoT scenarios.
Let me know if you want to explore this a little more, not for selling you anything, at least not yet, I would love to understand your use case. Let me know if you are open: ignacio[at]basekick[dot]net
Great questions, thanks!
Partitioning: yes, Arc partitions by measurement > year > month > day > hour. This structure makes time-range queries very fast and simplifies retention policies (you can drop by hour/day instead of re-clustering).
Small Parquet files: we batch writes by measurement before flushing, typically every 10 K records or 60 seconds. That keeps file counts manageable while maintaining near-real-time visibility. Compaction jobs (optional) can later merge smaller Parquet files for long-term optimization.
Updates/deletes: today Arc is append-only (like most time-series systems). Updates/deletes are planned via “rewrite on retention”, meaning you’ll be able to apply corrections or retention windows by rewriting affected partitions.
The current focus is on predictable write throughput and analytical query performance, but schema evolution and partial rewrites are definitely on the roadmap.
The benchmarks weren’t run on the same machine as MinIO, but on the same network, connected over a 1 Gbps switch, so there’s a bit of real network latency, though still close to local-disk performance.
We’ve also tried a true remote setup before (compute around ~160 ms away from AWS S3). I plan to rerun that scenario soon and publish the updated results for transparency.
Regarding “hot vs. cold” data, Arc doesn’t maintain separate tiers in the traditional sense. All data lives in the S3-compatible storage (MinIO or AWS S3), and we rely on caching for repeated query patterns instead of a separate local tier.
In practice, Arc performs better than ClickHouse when using S3 as the primary storage layer. ClickHouse can scan faster in pure analytical workloads, but Arc tends to outperform it on time-range–based queries (typical in observability and IoT).
I’ll post the new benchmark numbers in the next few days, they should give a clearer picture of the trade-offs.
I didn’t really worry about confusion since this isn’t a browser, it’s a completely different animal.
The name actually came from “Ark”, as in something that stores and carries, but I decided to go with Arc to avoid sounding too biblical.
The deeper reason is that Arc isn’t just about ingestion; it’s designed to store data long-term for other databases like InfluxDB, Timescale, or Kafka using Parquet and S3-style backends that scale economically while still letting you query everything with SQL.
That’s a fair question, and in theory, yes, you could manually track internal certs based on issue date.
But in practice, large or long-running environments rarely have clean cert inventories. You get:
- Internal CA sprawl (and no single source of truth)
Certs embedded in keystores, containers, or staging systems that nobody owns anymore
- “Temporary” certs that live on for years
- People leaving without handing off cert responsibilities
We’re not automating monitoring because it’s hard, we’re doing it because teams forget.
And forgetting is what causes outages, broken mTLS, and failed compliance audits, even in air-gapped setups. I have a few horror story on PCI environments.
Automation helps catch the edge cases before they become fire drills.
Totally fair, and for a single cert or a tightly controlled setup, a calendar reminder might be “enough.”
But in practice, it tends to break down when:
- Certificates multiply across internal services, vendors, CDNs, load balancers, staging/prod, and even IoT or embedded devices.
Ownership is unclear, people leave, and calendar invites don’t update themselves.
No visibility, unless someone’s checking regularly, you won’t know if a cert was rotated early, replaced with a shorter one, or removed entirely.
No alerting or state tracking, a calendar doesn’t notify you if someone messed up the renewal or if the cert is already expired.
No integration with the rest of your monitoring/incident tooling.
SSL Guardian gives you a real-time dashboard of every cert, expiration tracking, and actual notifications, so you’re not relying on tribal knowledge, calendar hygiene, or someone noticing too late.
We’re not trying to over-engineer a reminder, we’re replacing a fragile human process with something that scales across orgs and environments.
Dont ask me more how I know that a calendar doesn't work lol!
We're building a lightweight collector (RTCollector) you can run inside the air-gapped environment. It can read from local cert stores (JKS, PKCS#12, PEM, etc.), extract metadata like expiration date and fingerprint (no private keys or cert contents), and send it out securely when outbound connectivity is available.
We already have an api endpoint in place, so you can push data using Python, Bash, curl, or anything else that fits your workflow. No agent required, just a simple POST.
Totally fair, for public-facing web servers, Traefik, Caddy, and Let’s Encrypt have made things nearly zero-effort. It’s amazing how far we’ve come.
That said, a lot of enterprise environments still deal with:
- Air-gapped networks (no LE/ZeroSSL reachability)
- Mutual TLS between services, where certs aren’t tied to domains
- Manually issued certs from internal or private CAs (often via ticketing systems)
- Non-HTTP workloads that don’t play well with ACME automation
In those cases, certs are still a bit of a pain, especially when ownership is unclear or spread across teams. SSL Guardian aims to help in those more chaotic setups, not just the clean webserver use cases.
That’s a sentiment I hear a lot, and honestly, not without reason. The trust model behind public CAs is… fragile at best. Misissuances, opaque root store politics, and uneven auditing make it feel like we’re outsourcing security to a cartel.
But until there’s a widely adopted alternative (DANE, peer-to-peer trust, Web of Trust 2.0?), we’re stuck maintaining vigilance within this system. And unfortunately, the shorter cert lifecycles and increasing complexity only make that harder.
Absolutely, this shift toward shorter cert lifetimes is going to make monitoring even more critical.
Automation will help, but with 90-, 100-, and eventually 47-day cycles, the margin for unnoticed renewal failures shrinks fast. One bad deploy, broken ACME challenge, or DNS hiccup, and you’re suddenly inside the failure window before anyone notices.
It’s a good time for teams to review their cert workflows, not just issuance, but visibility and alerting too. I built SSL Guardian with that trend in mind, but even if you’re rolling your own monitoring, this change is going to raise the bar for how tightly we need to watch certs.
You’re absolutely right, SSL monitoring isn’t a new problem. Tools like Nagios, Zabbix, and many SaaS providers have offered uptime and cert checks for years.
What I found lacking (especially for modern teams) was:
- Multi-domain, multi-tenant tracking with clean dashboards, most tools either require scripting or feel like they’re stuck in 2005.
- Ownership context: who owns which cert, what service depends on it, and whether it’s internal, public, or handled by a vendor.
- Fast visibility for teams with fragmented infrastructure: CDNs, cloud load balancers, custom pipelines, etc.
So yeah, the core idea isn’t new, but the execution is built for today’s hybrid and messy realities. Think of it as Nagios built by someone who has had to explain expired certs to a customer at 6am.
Totally, Traefik + certbot automation works well in many setups.
But I’ve seen cases where cert renewal fails silently (DNS misconfig, HTTP challenge blocked, clock drift, etc.) and no one notices until users start seeing browser warnings.