Most databases were not built for time series. They can store timestamped rows, but they were designed for transactions and relationships, not for a firehose of measurements arriving every millisecond from thousands of sensors. When your dominant access pattern is "what happened over this time range" and your write volume is millions of points per second, a general-purpose relational database starts to buckle — single range queries scan millions of rows, indexes bloat, and storage costs spiral. InfluxDB was built for exactly that workload, and in 2026 it is a different beast than it was a few years ago.
InfluxDB 3 Core is an open-source (MIT/Apache-2.0), single-node time-series engine with roughly 31,000 GitHub stars, rewritten in Rust on the FDAP stack — Apache Arrow, DataFusion, Flight, and Parquet. It ingests continuously, queries recent data in single-digit milliseconds, and stores on object storage with Parquet. It is the foundation that InfluxData's commercial Enterprise and Cloud products build on, and that split — open-source Core versus closed-source Enterprise — is the most important thing to understand before you adopt it. This is a long, honest teardown of what InfluxDB 3 delivers, how the v3 architecture works, why the rewrite broke compatibility with v1/v2, the built-in Python processing engine, the hard limits of the free tier, and precisely where your telemetry lands.
1. What InfluxDB Is For
InfluxDB is a purpose-built time-series database. Its data model centers on measurements associated with timestamps: sensor readings, server metrics, network telemetry, financial ticks, application events. Workloads that arrive continuously and are queried by time range are its sweet spot. Monitoring, IoT and industrial sensors, energy storage systems, network operations, financial market analytics, and behavioral event streams all fit.
The design priority is write throughput and fast time-range queries. InfluxDB 3 Core targets sub-10ms access to recent data and can handle high-cardinality series (millions of unique series) without the performance cliffs that plagued earlier designs. That makes it the engine behind a large share of self-hosted monitoring stacks, often paired with Telegraf for collection and Grafana for visualization (both of which we cover in this series).
2. The v3 Rewrite: Rust and the FDAP Stack
The story of modern InfluxDB is the v3 rewrite. Earlier versions (1.x in Go, 2.x also Go) reached scaling and cardinality limits that a rewrite addressed. v3 is written in Rust and built on the FDAP stack:
Apache Arrow for columnar in-memory format,
DataFusion for the SQL query engine,
Flight (Arrow Flight SQL) for the wire protocol, and
Parquet for on-disk persistence. This combination is the modern, high-performance way to build a columnar analytical store, and it gives InfluxDB 3 both speed and the ability to leverage a mature query engine rather than maintaining a bespoke one.
For a self-hoster, the practical takeaway is that v3 is a genuinely different product from v1/v2. It is faster, handles cardinality better, and stores more cheaply on object storage — but it is not a drop-in upgrade. The data format, query behavior, and operational model changed. If you are starting fresh in 2026, v3 Core is the version to use. If you are running v1 or v2, migrating is a project, not a flag.
3. Diskless Architecture on Object Storage
A defining feature of InfluxDB 3 is its diskless architecture. Rather than managing its own local storage files exclusively, v3 persists data as Parquet on object storage — Amazon S3, Google Cloud Storage, or Azure Blob — or on local disk if you prefer. Compute and storage scale independently: you can run the engine on a small node and let object storage absorb the volume.
This is a meaningful shift for cost and operations. High-volume telemetry is cheap to keep in Parquet on object storage compared to bespoke TSM files on attached disks. It also simplifies backup: the data is already in your bucket, and object storage lifecycle policies can tier older data. The trade is that v3 now depends on the availability and latency of your object store for persistence — a local-disk deployment avoids that dependency, at the cost of giving up the scale-out storage story. Either way, the data lives where you point it, which is the sovereign requirement.
4. Ingest: Line Protocol and API Compatibility
Data enters InfluxDB via
line protocol, a terse text format:
measurement,tag=val field=val timestamp. It is designed to be written fast and parsed fast. v3 Core maintains compatibility with the InfluxDB 1.x and 2.x write APIs, so existing Telegraf configurations and collectors that speak those APIs keep working. That backward-compatible ingest is one of the smoother parts of the v3 transition — you can point your existing pipelines at a v3 instance without rewriting the write side.
Write performance is a headline strength: v3 is built for continuous, high-resolution ingest, handling millions of writes per second from thousands of devices in documented IoT deployments. For a self-hoster, you will rarely approach those ceilings, but the headroom means a single modest node comfortably handles a home-lab or small-business metric firehose.
5. Query: SQL, InfluxQL, and Flight SQL
v3 supports three query languages, which is more flexible than v1/v2'sInfluxQL-only world.
SQL is the primary engine, powered by DataFusion, so you can write standard SQL against your time-series tables — a big win for anyone who already knows SQL and does not want to learn a dialect.
InfluxQL, the legacy Influx query language, is supported for compatibility with v1 queries. And
Flight SQL provides a high-performance wire protocol for analytical clients.
The SQL support is the quiet revolution here. Time-series databases that forced a proprietary query language created a skill silo; v3's SQL engine lowers the barrier and lets the same queries join with other SQL data. The caveat is that time-series SQL still rewards understanding of windowing, downsampling, and time-bucket functions — the language is standard, but the analytical thinking is not.
6. The Built-In Python Processing Engine
One of v3's distinctive features is the
Processing Engine: a Python virtual machine embedded in the database that runs custom Python scripts directly on streaming data. Instead of shipping data to an external pipeline (Lambda, a separate worker) for transformation, anomaly detection, or enrichment, you can run that logic inside Core as data arrives.
For a sovereign operator, this is genuinely useful: transformations that used to require standing up a separate processing service can live next to the data, reducing moving parts and egress. The limitation is that the embedded Python environment is a constrained runtime — not a substitute for a full data platform — and complex multi-stage pipelines will still want an external orchestrator (n8n, covered in this series, is the natural companion). But for "enrich this measurement before it lands" or "flag anomalies in real time," the in-database engine removes a whole class of infrastructure.
7. Open Source Core vs Closed Enterprise: The Split
This is the section a sovereign operator must read before committing. InfluxDB 3 Core is open source under MIT and Apache-2.0 — free to download and run, no license key, no mandatory telemetry. InfluxDB 3
Enterprise is a commercial product built on the same engine, offering high availability, multi-node distribution, long-range historical queries, read replicas, workload isolation, and enterprise security/compliance (SOC 2, ISO, GDPR). Cloud Dedicated is the managed version.
The split is real and intentional. Core is the single-node, recent-data engine: optimized for recent data and millisecond queries, ideal for edge, IoT prototypes, and single-node production focused on current data. Enterprise adds the production-grade features — HA and historical depth — that most serious deployments eventually want. The honest framing: you can start free and open source, but the moment you need high availability or long-range history at scale, you cross into commercial territory. That is not a trap; it is the business model. But it must be a conscious decision, because the free tier's ceilings are architectural, not arbitrary.
8. What Core Does Not Give You
To make the boundary concrete: InfluxDB 3 Core is single-node. It is not a distributed cluster, and it does not provide the built-in high availability that Enterprise does. It is optimized for
recent data — fast queries on the hot set — rather than arbitrarily long historical ranges at full resolution. If your requirement is "query five years of per-second data with HA and no downtime," that is Enterprise's job, not Core's.
This is the bit that surprises people who adopted InfluxDB years ago on the assumption that "open source" covered everything. The open-source Core is real and capable, but it is explicitly the entry tier. The production hardening lives in the paid product. A self-hoster running a single node for current metrics is perfectly served by Core; a team needing redundancy and deep history must budget for Enterprise or accept Core's limits.
9. Installation and Operation
InfluxDB 3 Core deploys with a single command — the official install script pulls and runs the binary, and the container image is equally straightforward. There is no cluster to manage in Core mode, which keeps operations light. Configuration centers on pointing it at storage (object store or local disk), setting the query and write ports (HTTP on 8181 by default), and — if you use the processing engine — the Python environment.
Operational maturity is the usual platform tax. You will want monitoring of the InfluxDB process itself (Uptime Kuma, covered in this series, is a simple way to alert on it), capacity planning for ingest rate, and a backup strategy for the storage layer. For object-storage deployments, backup is largely "your bucket is already durable, plus lifecycle/versioning"; for local disk, it is "snapshot the data directory." Either way, treat the storage as the thing you must not lose.
10. Pairing with Telegraf, Grafana, and Friends
InfluxDB rarely stands alone. The canonical self-hosted observability stack is
Telegraf (InfluxData's open-source collector, with 400+ input plugins) feeding InfluxDB, and
Grafana (covered in this series) querying it for dashboards. Telegraf's broad plugin catalog means you can collect from systems, containers, network gear, and custom sources without writing collectors. Grafana's InfluxDB datasource speaks the v3 SQL/Flight endpoints and renders the dashboards.
This composition is the strength of the ecosystem: each piece does one job, and they interoperate over open protocols. For a home-server monitor, the well-trodden path is Telegraf + InfluxDB 3 Core + Grafana, all self-hosted, with no vendor lock-in beyond the InfluxDB Core/Enterprise boundary. Home Assistant (covered in this series) can also ship metrics to InfluxDB for long-term graphing beyond its own recorder. The point is that InfluxDB slots into a sovereign stack cleanly; it is a component, not a walled garden.
11. InfluxDB vs TimescaleDB and Friends
The main alternative in the time-series space is
TimescaleDB, a PostgreSQL extension. TimescaleDB keeps you inside full SQL and PostgreSQL's ecosystem, with joins and relational features InfluxDB does not emphasize, at the cost of being less purpose-built for pure high-ingest time series. The rule of thumb: choose InfluxDB for pure time-series with extreme write performance and cheap object storage; choose TimescaleDB when your time-series data lives alongside relational data you want to join in one SQL engine.
Other contenders include QuestDB and VictoriaMetrics, each with different trade-offs (QuestDB chases ultra-low-latency ingest; VictoriaMetrics optimizes for cost-efficient long-term storage). None of these change the core decision: if your workload is "timestamped measurements at volume," a time-series database beats a general RDBMS, and InfluxDB 3 is the open-core option with the largest ecosystem.
12. Real Costs of Running InfluxDB 3 Core
The direct cost of Core is zero in license fees — MIT/Apache-2.0, no key, no telemetry. The infrastructure cost is the storage you choose: object storage at your cloud's rates, or local disk you already own. Compute is modest for Core; a small node handles substantial ingest. The hidden cost is the Enterprise cliff: if you later need HA or deep history, the commercial product has a price, and migrating your mental model (and possibly your tooling) to it is work. For a self-hoster who stays within Core's single-node, recent-data envelope, the cost story is about as good as open source gets.
13. Where Your Data Goes
Sovereignty question, answered directly: with InfluxDB 3 Core, your time-series data lands in the storage you configure — an S3/GCS/Azure bucket you control, or a local disk you control. There is no mandatory telemetry shipping your metrics to InfluxData; the open-source Core does not require a license key or phone home to function. Your data is your data, in a standard Parquet format on your storage.
The one nuance: if you use InfluxDB Cloud (the managed product), your data naturally lives with InfluxData's infrastructure — that is the trade for not operating it yourself, and it is a different product from self-hosted Core. For self-hosted Core, the data path is entirely yours. The processing engine's Python scripts run in your process on your data; they do not exfiltrate it. This is a clean sovereignty story for the self-hosted deployment, and it is the configuration we recommend for a sovereign operator.
14. Migration From v1/v2: The Honest Difficulty
If you are running InfluxDB 1.x or 2.x and considering v3, plan for a migration project. v3 shares the write API (so ingest keeps working) and supports InfluxQL for query compatibility, but the storage engine, internal data layout, and operational model differ. Moving existing data from TSM-based v1/v2 storage into v3's Parquet object store is not a file copy; it is an export/import or dual-write exercise.
The pragmatic path many take is to stand up v3 Core alongside the old instance, dual-write during a transition, and cut over queries once confidence is high. For greenfield 2026 deployments, none of this applies — start on v3 and skip the legacy entirely. The point is only that "upgrade InfluxDB" is not a one-flag operation across the v2→v3 boundary; treat it as a migration.
15. Schema and Data Modeling for Time Series
Although v3 speaks SQL, time-series modeling still rewards discipline. Use tags (indexed, low-cardinality dimensions like
host or
region) for the axes you filter and group by, and fields (the actual measurements) for the values you aggregate. Avoid high-cardinality tags (e.g., putting a per-request UUID as a tag) — that is the classic InfluxDB mistake that explodes index size. Design measurements around the queries you will run: if you always query "CPU by host over the last hour," model
host as a tag and
cpu as a field.
v3's better cardinality handling than v1/v2 means you can get away with more, but the principle holds. Good modeling is what turns "queries are slow and storage is huge" into "queries are instant and storage is cheap." The SQL engine will happily run bad queries against bad models; the database cannot save you from a poor schema.
16. Downsampling and Retention
A time-series best practice InfluxDB encourages is downsampling: keep high-resolution data for recent windows and roll it up to coarser aggregates for the long term. v3's processing engine or external tasks can compute hourly/daily rollups and store them as separate measurements, so "last 24 hours at one-second resolution, last year at one-hour resolution" becomes cheap and fast. Retention policies then expire the fine-grained data on a schedule.
This matters because "store everything forever at full resolution" is the fastest way to balloon storage and slow queries. For a self-hoster, a simple retention-plus-downsampling plan keeps InfluxDB lean and your object-storage bill modest. It is operational work, but it is the difference between a stack that scales and one that quietly accumulates debt.
17. Security and Exposure
InfluxDB 3 Core listens on HTTP (8181) for write and query. By default, you should not expose that port to the public internet; put it behind a reverse proxy (Caddy, covered in this series) with TLS and access control, and restrict who can write. v3 supports authentication and authorization, but the posture is your responsibility: an open InfluxDB write endpoint is an invitation for anyone to inject metrics (or exhaust your storage). For internal monitoring, bind to the local network and front it with the same auth gate you use elsewhere. The database does not assume your network topology; secure it like any other stateful service.
18. Who Should Run It, and Who Shouldn't
InfluxDB 3 Core is for the operator with continuous timestamped data: server and app metrics, IoT sensors, energy monitoring, financial ticks, event streams. Homelabs, small businesses, and edge deployments with single-node, recent-data needs are the sweet spot, and the open-source Core serves them fully. If you want SQL-native time-series with cheap object storage and an in-database processing engine, it is an excellent choice.
It is not for you if you need a distributed, HA, multi-node cluster on the open-source tier — that is Enterprise. It is not for you if your data is fundamentally relational and only incidentally time-stamped; TimescaleDB will serve you better. And it is not for you if you cannot accept that "open source" here means "open-source entry tier" with a commercial ceiling above it. Know the boundary, and Core is a gift; ignore it, and you will be surprised at the wrong moment.
19. The Sovereignty Verdict
Weighing InfluxDB 3 for sovereignty yields a qualified but positive verdict. On data, it is clean: self-hosted Core keeps your telemetry in storage you control, in open Parquet, with no mandatory telemetry. On license, it is the familiar open-core pattern — the free tier is genuinely open (MIT/Apache-2.0) and capable, while the production-hardening tier is commercial. For the vast majority of self-hosters, Core's single-node, recent-data envelope is more than enough, and the open-source license is real, not a teaser. The risk to govern is the future need for HA or deep history, which is the moment the commercial product becomes relevant.
The sovereign move is to deploy Core, keep your data in your own bucket, and design within its single-node envelope. Do that, and you get a fast, open, self-owned time-series engine without surrendering your metrics to a vendor — which is exactly the point of self-hosting.
20. A Concrete Walkthrough: Home-Server Monitoring
To make it concrete, imagine monitoring a home server. You install Telegraf with the system and Docker input plugins; it collects CPU, memory, disk, and container stats and writes them via line protocol to InfluxDB 3 Core on the default 8181 port, bound to your internal network. You point Grafana (covered in this series) at InfluxDB's SQL endpoint and build dashboards showing per-host CPU over the last hour. You add a processing-engine Python script that flags any temperature reading above a threshold in real time. You set a retention policy to keep detailed data for 30 days and downsample to hourly rollups for a year. Within an hour you have a self-owned, open-source monitoring backend — no cloud metrics service, no per-host fee, your data in your bucket.
21. High Cardinality: The Classic InfluxDB Killer, and How v3 Tames It
High cardinality — the number of unique series defined by the combination of measurement and tag values — has historically been the thing that brings time-series databases to their knees. A naive model that uses a per-request UUID or a user ID as a tag can explode into millions of series, bloating indexes and slowing every query. Earlier InfluxDB versions struggled past certain cardinality thresholds. v3's Rust engine and Parquet storage handle cardinality far better, but the principle is unchanged: model tags as low-cardinality dimensions (host, region, service) and keep high-cardinality values as fields, not tags. The practical rule is simple to state and hard to enforce on a team: anything that is unique per event does not belong in a tag. v3 gives you more headroom, not a license to abuse cardinality. The operators who run into trouble are almost always the ones who treated tags as a free-form labeling system rather than a deliberately bounded indexing axis.
22. Flight SQL and the Arrow Ecosystem
InfluxDB 3 speaks Arrow Flight SQL, a high-performance columnar wire protocol built on gRPC and Apache Arrow. For analytical clients, Flight SQL is dramatically faster than row-based HTTP for bulk result transfer, because data moves in Arrow's columnar format without serialization round-trips. This matters when you are pulling large windows of high-resolution data into a notebook, a training pipeline, or another analytical system. It also places InfluxDB inside the broader Arrow ecosystem: any tool that speaks Arrow Flight can talk to it efficiently. For a self-hoster, the day-to-day dashboard queries go over HTTP SQL and you never think about Flight; but if you build data-science or ML workflows on your telemetry, Flight SQL is the fast lane, and it is a genuine differentiator versus systems locked to JSON-over-HTTP.
23. Backups and Disaster Recovery
Because v3 is diskless and stores Parquet on object storage (or local disk), backup strategy follows the storage you chose. For object storage, enable bucket versioning and object lock so accidental or malicious deletes are recoverable, and use lifecycle policies to tier cold data to cheaper classes. The data is already in a durable, standard format, so "backup" is largely "your bucket is durable plus you have a copy elsewhere." For local-disk deployments, snapshot the data directory on a schedule and ship the snapshot off-host. The one thing v3 changes versus classic InfluxDB is that you are no longer backing up a bespoke TSM directory — you are backing up Parquet files, which any tool that reads Parquet can inspect. That portability is a quiet sovereignty win: your historical metrics are not trapped in a proprietary on-disk format.
24. Performance Tuning: Ingest and Query
For most self-hosted deployments, InfluxDB 3 Core needs little tuning — it is fast out of the box for recent data. The levers that matter are few. On ingest, batch writes (many points per line-protocol request) far outperform one-point-per-request; Telegraf does this for you, but custom writers should batch. On query, rely on time-range predicates and downsampled rollups rather than scanning raw high-resolution data for long windows. On storage, prefer object storage with good throughput if you query historical data heavily; local NVMe is best if your working set fits on disk and you want lowest latency. The processing engine's Python scripts add per-point compute, so keep them lean — a heavy script on a high-ingest stream is the easiest way to fall behind. None of this is exotic; it is the ordinary discipline of matching workload shape to engine behavior.
25. Common Pitfalls and How to Avoid Them
A short list recurs. Exposing the 8181 port to the internet without auth — don't; bind internal and front with a proxy. Using high-cardinality values as tags — covered above, the cardinal sin. Expecting Core to be a multi-node cluster — it isn't; that's Enterprise. Treating v2→v3 as a flag flip — it's a migration. Forgetting retention so storage grows unbounded — set a policy. Writing one point per request at high volume — batch. Relying on Core for years of full-resolution history — downsample. And the quiet one: assuming "open source InfluxDB" means "all of InfluxDB is open source" — only Core is; Enterprise is commercial. Each pitfall is avoidable with the discipline this article has emphasized, and none of them is a flaw in the engine so much as a mismatch between expectation and the open-core boundary.
26. InfluxDB in the IoT and Industrial Context
InfluxDB's lineage is deeply tied to IoT and industrial telemetry, and v3 is built for it. Factories, energy storage systems (BESS), and sensor networks generate exactly the high-frequency, high-cardinality, append-mostly workload the engine loves. A single Core node can ingest millions of writes per second from thousands of devices, and the object-storage backing means a year of sensor data costs little to keep. The processing engine's in-database Python is particularly valuable at the edge: you can detect anomalies or compute aggregates on-device-ish, before data even leaves the site. For a sovereign operator running an industrial or agricultural sensor network, InfluxDB 3 Core is one of the most pragmatic open-source choices — provided the single-node envelope matches the deployment, which for edge and mid-size IoT it usually does.
27. Comparing Editions: Core vs Enterprise
To make the boundary explicit rather than implied: InfluxDB 3 Core is single-node, optimized for recent data, open-source (MIT/Apache-2.0), with no HA and no built-in multi-node distribution. InfluxDB 3 Enterprise adds high availability, single- and multi-node architectures, long-range historical queries, read replicas, workload isolation, and enterprise security/compliance (SOC 2, ISO, GDPR). Cloud Dedicated is the fully managed form. The upgrade path is advertised as "seconds" — you keep the same engine and add nodes — but the commercial relationship begins the moment you need those production features. For a self-hoster, the honest assessment is that Core covers the overwhelming majority of non-redundant, recent-data use cases, and Enterprise is for organizations that cannot tolerate a single node being a point of failure or that must query deep history at scale.
28. Integrating with Message Queues and Streams
InfluxDB often sits at the end of a pipeline rather than the beginning. Telemetry frequently arrives via MQTT (from IoT devices), Kafka, or a message bus, and a collector or stream processor fans it out to InfluxDB. Telegraf handles many of these inputs natively, including MQTT and a wide range of system and service inputs. For more complex routing, an orchestrator like n8n (covered in this series) can subscribe to a queue, transform messages, and write line protocol to InfluxDB, pairing neatly with the in-database processing engine for the final shaping. The point is that InfluxDB is a destination and a query layer, not usually the ingestion router — designing the pipeline around that fact keeps the architecture clean and lets each component do its one job.
29. Observability of InfluxDB Itself
The one blind spot in any monitoring stack is the monitor. If InfluxDB goes down and it is your metrics store, you may not notice because the dashboard depends on it. The fix is to monitor InfluxDB from outside: a simple external check (Uptime Kuma, covered in this series) can alert when the HTTP endpoint stops responding, and shipping InfluxDB's own internal metrics to a second, independent location avoids the "monitoring monitored by itself" trap. For a sovereign operator, the discipline is to ensure that the failure of any single component is visible from a component that does not depend on it. InfluxDB is robust, but like any stateful service it can fail, and the cost of an unseen failure is the loss of the very visibility you relied on it to provide.
30. The v3 Storage Format and Future-Proofing
A subtle but durable advantage of v3 is that your historical data lives as Parquet — an open, columnar format with a vast ecosystem of readers — on object storage you control. Unlike a bespoke time-series on-disk format that only the originating database can parse, Parquet can be read by DuckDB, Spark, Pandas, and a long list of analytical tools without InfluxDB in the loop. That means even in a worst-case scenario where you abandon InfluxDB, your archived telemetry remains queryable by standard tooling. For a sovereign operator, format portability is a form of insurance: the data you collect today should not require the vendor's engine to ever be useful. v3's choice of Parquet on object storage is, whether intentional or not, a strong signal that your data is yours — and that is exactly the posture self-hosting is supposed to deliver.
31. When Not to Use a Time-Series Database
The disciplined answer to "should I use InfluxDB" includes knowing when not to. If your data is primarily relational — customers, orders, invoices — with timestamps only as one attribute, a general RDBMS or a Postgres extension like TimescaleDB serves you better, because you need joins, transactions, and referential integrity that a time-series engine does not prioritize. If your volume is low (a few writes per minute), almost any database handles it and the operational simplicity of "just use Postgres" wins. If your queries are not time-range-centric — you mostly look up by ID, not by "last hour" — a time-series store adds cost without benefit. And if you need a distributed, HA cluster on the open-source tier, InfluxDB 3 Core will not provide it; you would be adopting the commercial edition or choosing a different tool. The right move is to match workload shape to engine: time-series at volume, choose InfluxDB; everything else, choose accordingly.
32. The Bottom Line
InfluxDB 3 Core is, for the right workload, close to the ideal self-hosted time-series engine: open-source under MIT/Apache-2.0, written in Rust for speed, storing your data as open Parquet on storage you control, with SQL you already know and an in-database Python engine for real-time work. Its limits are architectural and clearly drawn — single-node, recent-data, open-source; HA and deep history in the commercial Enterprise tier. Go in with eyes open about that boundary and Core will serve a homelab or small deployment for years without a license fee or a vendor. The sovereign operator's recipe is simple: deploy Core, keep your data in your own bucket, model tags with discipline, downsample aggressively, and monitor the monitor. Do that, and your telemetry stays fast, cheap, and unmistakably yours.
Related
For the rest of a sovereign, self-hosted stack, these pieces from our series travel with InfluxDB:
Comments (0)
No comments yet. Be the first to comment!