ignaciovdk

Very cool!

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.

Happy to answer questions.

Arc is OSS under AGPL-3.0: https://github.com/Basekick-Labs/arc

Two weeks ago, we open-sourced Arc Core: https://github.com/Basekick-Labs/arc

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.

Full technical breakdown and benchmarks: https://basekick.net/blog/arc-fastest-timeseries-database-cl...

Happy to answer questions about the architecture, design decisions, or benchmarking methodology.

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.

Thanks! Let’s go by parts, as Jason would say

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.

Hey, thanks for asking.

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.

Hey there, great questions.

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.

Awesome, would love to hear what you think once you try it out!

If it’s not too much trouble, feel free to share feedback at ignacio [at] basekick [dot] net.

Hey, good question!

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.

Caddy is great for automated cert management, probably one of the cleanest out there.

But in environments where you don’t control the full stack (e.g. legacy infra, third-party APIs, multi-cloud setups), or when certs are provisioned manually or via external teams, things get trickier. Expiry issues still happen more often than we’d like.

That’s what led me to build SSL Guardian, more as a safety net to monitor certs across various sources and alert before things break. Even with automation, having external validation helps avoid blind spots.

Ever had your site or API go down because of an expired SSL certificate? It happened to us, and the fix was surprisingly painful. So we built SSL Guardian, a simple, automated SSL/TLS monitoring platform.

What it does:

- Tracks SSL/TLS certificates across all your domains and services - Sends timely alerts (Email, Slack, Webhooks) - Performs chain validation and health checks - Quick setup, zero vendor lock-in

Why? Because one missed renewal can mean hours of downtime, lost trust, and customer churn.

We’re offering free access for early testers (Pro plan for 12 months) in exchange for feedback.

Try SSL Guardian

Would love your thoughts on: - How do you handle SSL/TLS monitoring today? - Biggest pain points you’ve hit? - Features you’d want in a tool like this?

Hey HN,

After two decades in tech (Microsoft, startups, data platforms, the works), I realized I was spending more time explaining my job than actually doing it.

Especially as a Solutions Architect / Sales Engineer — one of the most misunderstood roles in the game.

So I started a weekly newsletter called Architect This. It’s part therapy, part insight, part "why does no one know what this job actually is?"

I write about: - What SAs and SEs really do (hint: it's not just demos and diagrams) - How we bridge chaos, customers, and roadmaps - The daily emotional rollercoaster of pre-sales, onboarding, and fixing things we didn’t break

If you've ever: - Fixed a broken dashboard while explaining it to a customer - Been told "just do a quick demo" with no prep - Acted as the translator between sales promises and engineering reality

…then yeah. This one's for you.

Would love feedback, stories, war flashbacks, etc.

Hey HN,

We’re running a developer-driven research project on how teams are using and paying for managed databases (AWS RDS, Neon, Xata, Supabase, self-hosted).

- How much do you actually spend on databases? - What problems do you face with cost, scaling, or HA? - What’s your biggest frustration with your current setup?

If you use PostgreSQL, InfluxDB, ClickHouse, or Redis, we’d love your insights!

Survey (2 min, no email required): https://app.formbricks.com/s/cm6r296dm0007l203s8953ph4

We’ll share anonymized results in a follow-up post!

Hi, great questions. We are running a few actions to understand if theres a need for this, then, a MVP with the team + a few extra drivers should help to understand that a little bit more, what do you think?

Learning about Vector databases and looking for a new job :D

Learn how to build a time-series data storage system using blockchain with this fun guide. Explore setting up Ethereum with Ganache, deploying smart contracts with Solidity and Truffle, and using Python to store and retrieve time-series data like temperature and humidity.

We used Ockam at Voltmetrix and we are offering to our customers to secure their connections between applications and I think that is the most valuable here, connect applications, not entire networks.

Hey, Hacker News community! I'm Ignacio, Co-Founder and CTO of Voltmetrix.

I wanted to share something I'm genuinely excited about: Voltmetrix, our next-gen hosted and managed data platform, tailored for IoT, Observability, and Analytics.

We're all about making life easier for developers, engineers, and data scientists. With Voltmetrix, you can say goodbye to the hassle of maintaining infrastructure for data storage and visualization. Imagine deploying MySQL, InfluxDB, Grafana, ClickHouse, TimescaleDB, and more in minutes, not hours - all on your favorite clouds like Google Cloud, AWS, Microsoft Azure, and DigitalOcean.

Security? We've got it covered. Everything is encrypted, both at rest and in transit, so your data's safe with us.

The best part? It's managed and hosted. That means you focus on what's important - your application and data, while we handle the infrastructure, security, and maintenance. Plus, we include 24/7/365 monitoring and alerting, so you're always in the know.

And it doesn't matter where you are; with Voltmetrix, you've got global coverage in over 60+ regions across four clouds. Plus, we're constantly expanding.

Need support? We offer 5x8, with an optional 24x7 service, covering both the solutions we offer and the underlying infrastructure.

I’d love to hear your thoughts or answer any questions. We're here to help developers and data scientists get the most out of their data in real-time, without the infrastructure headaches.

Cheers!