Kentik and the data engine that turns network flows into evidence

Summary

• Kentik Data Engine, or KDE, is the proprietary distributed columnar datastore at the centre of Kentik’s network-intelligence platform; it is a Kentik product architecture rather than a separate company or open-source database
• KDE receives flow records and related telemetry, maps heterogeneous fields, and enriches records with routing, geography, interface, site, threat and business context so operators can ask questions about networks, customers, providers, applications and cost
• The engine maintains separate full and fast dataseries for different analytical purposes, while time slices are replicated across workers and master nodes divide and reassemble distributed queries
• Every result inherits the limitations of the underlying telemetry: sampling, missing exporters, provider-specific cloud semantics, stale interface labels, imperfect GeoIP and incomplete BGP context can all survive inside a precise-looking query result
• Infoblox announced a definitive agreement to acquire Kentik on 8 July 2026, proposing to combine DNS, DHCP, IPAM and asset context with Kentik’s traffic and path evidence; at the source cutoff, the transaction remained subject to approvals and closing conditions

A network cannot investigate evidence it failed to keep

Many network incidents are obvious only after the conditions that produced them have changed. A congested interconnection clears. A route announcement is withdrawn. An interface description is corrected. A cloud workload moves to another region. A customer reports poor performance hours after the path has recovered. By then, a device dashboard may show a healthy present while the operational question belongs to the past.

The team therefore needs more than current counters. It needs a record of what traffic was observed, where it entered, which route context was available, which interface and site labels were attached, and how the evidence changed over time. Without that retained history, an investigation becomes an exercise in reconstructing a vanished state from logs, screenshots and memory.

Traditional monitoring architectures often divide that record among several systems. Routers export flow telemetry. BGP collectors describe reachability and path attributes. Device-management tools collect interface counters and state. Synthetic agents probe selected paths. Cloud providers publish their own flow logs and resource metadata. Incident responders then move among those systems, comparing timestamps and manually rebuilding the sequence of events.

Kentik’s original proposition was to preserve much of that evidence inside one analytical environment and make historical questions fast enough to support operations rather than only a later forensic exercise. The problem is not simply storage. Network telemetry combines high ingest rates, time-dependent dimensions, many addresses, ports, autonomous systems, interfaces and paths, and repeated requests to regroup the same observations according to different operational questions.

A capacity planner may want monthly traffic by provider. A peering engineer may want destination ASN and interconnection. A security analyst may want to know when an unexpected source pattern began. A cloud team may want to compare one region with another. Each request uses much of the same underlying evidence while applying a different frame.

KDE exists to preserve those records, attach network and business context, and distribute the query work across a purpose-built system. Its strongest description is therefore not simply “database”. It is a network memory with an analytical contract: evidence is stored and made queryable, but the result remains bounded by what the collection system actually observed.

Kentik Data Engine is not a separate company

The distinction between Kentik and KDE is important in a company profile. Kentik Data Engine is the analytical substrate beneath the broader Kentik commercial platform. It is not a separate corporation, not a separately governed business and not a general-purpose open-source database.

Kentik Technologies operates the service, employs the teams that build and maintain it, sells the surrounding platform and contracts with customers. KDE sits beneath dashboards, alerts, traffic analytics, cloud views, device monitoring, synthetic testing, internet intelligence, cost analysis and other product workflows. Those applications can query evidence stored in KDE or contribute additional context, but they should not be treated as synonyms for the engine itself.

The boundary matters because commercial and technical claims belong to different layers. A Kentik financing round is company-level capital, not a valuation of KDE. An application feature may rely on the engine without revealing how the engine is physically implemented. An acquisition of Kentik would transfer corporate control if it closes, but it does not make an announced combined product architecture real before the integration exists.

Several adjacent technologies can also blur the picture. NetFlow, sFlow and IPFIX are telemetry formats or sources, not storage engines. BGP collectors provide routing evidence, not a complete enriched customer flow history. A SIEM or general data lake may store some similar inputs, but KDE is organised around network-specific dimensions and workflows.

General analytical systems such as ClickHouse, Apache Druid, BigQuery or Snowflake can be alternatives for organisations that want to build their own network-analytics stack. The supplied evidence does not establish KDE as a fork, wrapper or renamed version of any of them. The responsible claim is narrower: Kentik describes KDE as its custom-built distributed columnar datastore.

That product boundary should remain visible throughout the article. Kentik is the company. Kentik’s platform is the commercial service environment. KDE is the data engine inside that platform. Individual applications are customer-facing workflows above it. The company’s future ownership after a pending transaction is a separate legal question again.

CloudHelix began with the problem of retained flow evidence

The company behind KDE began as CloudHelix in January 2014, founded by network-operations veterans. An early seed financing followed that year. On 30 June 2015, the business launched the Kentik brand and an early flow-analytics service.

The supplied evidence does not identify one formal date on which the datastore itself was “founded”. KDE developed with the product. Early architecture material from 2015 and 2016 already described the core proposition: ingest large volumes of flow telemetry, enrich those records with internet and routing context, store them in clustered columnar infrastructure and retain enough history to answer operational questions.

At that stage, the company was more visibly a flow-analytics vendor. The engine was close to the customer story because the product promise depended directly on storing and querying high-cardinality traffic history. Later dashboards and packaged applications had not yet placed as much product abstraction above the datastore.

Financing increased Kentik’s capacity to turn that architecture into a commercial service. The company announced a $23 million Series B in 2016, $23.5 million in growth funding in 2020 and a $40 million Series C in October 2021. Kentik said cumulative funding had reached about $102 million after the Series C.

Those figures belong to the company. They establish capital raised, not KDE development cost, product-level revenue, gross margin or standalone valuation. No evidence supplied for this profile breaks the financing down by engineering system.

The product broadened as the company did. From 2016 through 2020, Kentik added more packaged dashboards, alerting, APIs and operational workflows. Between 2020 and 2024, its portfolio expanded into cloud telemetry, synthetic testing, device monitoring, internet and market intelligence, path analysis and cost functions.

As the platform expanded, KDE became less visible as a named object in everyday use. Customers increasingly worked through applications that translated database operations into familiar network tasks. The engine remained central, but it became one layer inside a wider observability and network-intelligence system.

This history is also a warning against treating early architecture documents as a complete description of the current physical implementation. The durable ideas are retained flow evidence, contextual enrichment and distributed analytical execution. The precise node count, storage technology, scheduling policy, failure-domain layout and tenant implementation are not disclosed in enough current public detail to assume that every early architectural choice remains unchanged.

A flow record is a summary produced at an observation point

A flow record is not a packet capture. It is a structured summary generated by a router, switch, virtual network, cloud service or another exporter. It can describe endpoints, ports, protocol, bytes, packets, timestamps, interfaces and other fields available at that observation point.

That distinction limits what KDE can know. A flow record can show that a conversation was observed and support aggregation across time. It normally cannot reconstruct payloads, every packet-level timing detail or information the exporter never recorded.

Sampling makes the limit sharper. A router may inspect only a portion of packets and export a statistical representation. A cloud provider may aggregate or define records according to its own service semantics. A collector can receive every record that the source sends while the source itself has already reduced the traffic.

For that reason, descriptions such as “full-fidelity flow data” need careful interpretation. The defensible meaning is preservation of the submitted records within service limits, not a guarantee that every packet crossing a customer network was captured.

The observation point also determines meaning. A flow exported at an internet edge describes traffic as seen there. A record from an internal router may show a different interface or address translation state. A cloud flow log reflects the capture point and schema chosen by the provider.

Overlapping observation points can count related traffic more than once unless the query accounts for the collection design. Missing exporters create blind spots no downstream database can repair. If a router never exports the evidence, KDE cannot infer it later from retention alone.

Templates and field support add another dependency. Exporters tell collectors how to interpret records, and implementations vary in what they include. A malformed template, unsupported field, clock error or collection outage can create incomplete evidence. Long retention can preserve those defects for months.

For operators, this means KDE has to be designed with the exporter estate rather than treated as a system that begins at storage. Sampling rates, clocks, templates, observation points and collector-health alerts are part of the analytical chain. A result becomes reliable through that complete chain, not through a powerful datastore alone.

Flow, BGP, device state and synthetic tests answer different questions

Kentik’s broader platform brings several evidence types into one operating environment, but correlation does not make those evidence types interchangeable.

Flow telemetry describes conversations observed by exporters. BGP describes control-plane reachability and selected route attributes. SNMP or streaming telemetry reports counters and device state. Synthetic tests create controlled probes towards selected destinations. Cloud logs reproduce provider-defined observations.

A traffic increase in flow data may coincide with a rise in an interface counter, yet the two measurements have different collection paths and resolutions. A BGP route can be present while data-plane forwarding fails. A synthetic test can fail because the probe, DNS resolution or test path changed while most user traffic remains healthy. A cloud flow log can omit traffic that never crosses the provider’s selected observation boundary.

Kentik’s value lies in allowing those sources to be compared while preserving their different meanings. An operator investigating a complaint can ask whether traffic changed, whether route context shifted, whether an interface showed errors and whether a synthetic test observed loss or latency.

Agreement among independent signals can strengthen the operational case. Disagreement can be equally valuable because it may reveal a partial outage, a measurement defect or a question framed at the wrong layer.

Time complicates the comparison. Flow, routing, device and synthetic observations may arrive at different intervals. Enrichment can depend on the context available when data entered the system. A later BGP table does not necessarily describe the context attached to a historical record at ingest.

Responsible network intelligence therefore requires the analyst to think about timestamp, collection cadence and provenance rather than treating the platform as one perfectly synchronous snapshot. KDE is strongest when it supports correlation without hiding the fact that each signal observed a different part of the network.

Enrichment turns traffic into an operational question

Raw addresses, ports and byte counts are rarely the final unit of network work. A service provider wants to know which customer, transit supplier, peer or autonomous system is involved. An enterprise wants to know which site, application, cloud region or cost centre generated the traffic. A security team wants threat context and a way to distinguish familiar infrastructure from a suspicious source pattern.

KDE adds dimensions that make those questions possible. Kentik documentation describes enrichment with GeoIP, autonomous-system information, BGP path data, interface and site metadata, flow tags, custom dimensions and other platform context.

Some of that context comes from the customer environment. Some comes from routing sessions or reference data. Some is generated through Kentik’s own mapping and analytical logic. Once attached, the dimensions can be used repeatedly in filters, groups, dashboards and alert policies.

Precomputed enrichment can make recurring queries faster because the engine can filter a stored native dimension rather than evaluate the same rule over a broad historical dataset every time. Ingest-time context can also preserve how the platform classified a record at that moment.

The trade-off is that a wrong mapping can become part of the retained history. If a site, provider or business tag is wrong, later queries may deliver precise answers based on the wrong classification. The query can be technically correct and operationally misleading at the same time.

GeoIP illustrates the problem. A geographical label can support regional analysis, but IP-to-location data is imperfect and can lag change. Autonomous-system mappings can associate an address with a network, while origin, ownership and the path actually selected remain different questions. Interface descriptions are useful only when inventory is maintained. Threat intelligence can prioritise investigation without proving malicious intent.

Enrichment therefore needs governance. Teams should know where a dimension came from, when it was updated, which records used it and who owns corrections. The more the platform is used for cost allocation or automated action, the more this lineage becomes part of the control system rather than background metadata.

Universal Data Records manage heterogeneity without making every source identical

Network records vary across vendors, device families, software releases and cloud providers. A fixed schema designed around one exporter can become unwieldy as every possible field is added.

Kentik’s Universal Data Records mechanism addresses that problem by allowing heterogeneous fields to be mapped into the analytical environment. This supports a broader platform than classic NetFlow collection because device-specific and provider-specific data can enter the same query environment without forcing every record into one rigid sparse schema.

Where semantics align, common dimensions can be exposed. Where they do not, additional fields can remain source-specific. This improves extensibility and gives customers a route to bring specialised context into the platform.

Dynamic mapping does not remove semantic work. Two fields can have similar names and different units, timing or meaning. A vendor can change its output format. A cloud provider can revise a logging schema. A custom dimension can be populated inconsistently across business units.

The mapping layer therefore needs testing, versioning and explanation. Schema flexibility moves the problem from “Can this field be stored?” to “Can this field be interpreted consistently enough for the decision being made?”

That is especially important in cross-device queries. A portal can present one familiar dimension while the underlying values were supplied, derived or mapped in different ways. Universal Data Records are an extensibility mechanism, not proof that heterogeneous evidence has become semantically identical.

The architectural benefit remains substantial. A network platform that cannot absorb new fields will age quickly as infrastructure changes. KDE’s schema approach gives the engine room to evolve. Its continuing cost is parser maintenance, model governance and clear lineage for any dimension used in an operational decision.

Separate customer databases establish a logical tenancy boundary

Kentik’s current documentation says KDE maintains separate databases for customer flow records. Within that environment, device-specific main tables hold flow data and related fields, supplemental datasets contain derived context, and an all-devices view supports analysis across an organisation.

That separation is meaningful evidence of logical tenancy. It shows that customer records are not described as one undifferentiated global table. It does not, by itself, prove dedicated physical hardware, one particular encryption design, separate keys, a specific replication geography or isolation from every administrative path.

Those controls require security architecture, contractual and audit evidence beyond a public data-model description. The distinction matters because a logical data model and a physical isolation model answer different questions.

The all-devices view illustrates the trade-off between convenience and interpretation. It lets an operator compare traffic across a large estate without querying device tables individually. The same breadth can make a query conceptually loose if devices sit at different observation points, use different sampling rates or expose different dimensions.

Organisation-wide analysis therefore needs an explicit collection model. A single view should not conceal the fact that two devices may have observed related traffic from different places or under different telemetry rules.

Supplemental data introduces another provenance layer. A field may come directly from an exporter, from a routing table, from a reference database or from a rule. The logical table structure is therefore not merely an implementation detail. It is part of the explanation needed to judge what the result means.

For customers, the correct diligence question is broader than “Are databases separate?” Buyers should also examine residency, retention, access control, data export, audit scope, key management and administrative boundaries. Public documentation supports the logical-separation claim. It does not justify filling every unanswered control with an assumption.

Full and fast dataseries trade detail for query reach

KDE maintains two independent dataseries designed for different analytical purposes. The full dataseries contains records submitted to the engine within service and contractual limits. The fast dataseries is created separately at ingest from a subset designed to accelerate longer-window queries.

This dual structure addresses a familiar problem in telemetry systems. Detailed records are valuable for short-window investigation, but scanning high-cardinality data over weeks or months can be expensive. Capacity planning and trend analysis often need broader time reach more than record-level detail.

A parallel accelerated series gives those questions a smaller analytical surface while preserving the full series for work that needs the submitted record set. The two dataseries should not be treated as interchangeable simply because they are queried through one platform.

A chart based on the fast series may be suitable for identifying a long-term direction and unsuitable for reconciling a short incident or a small traffic class. Results can differ because resolution and the underlying populations differ.

The word “full” needs the same discipline. It describes the submitted records stored by KDE, not every packet in the source network. Sampling, field omission, collection failure and source-side aggregation can all occur before the full series receives the data.

Operationally, teams should preserve the chosen dataseries, time range, device scope and resolution with the analytical result. Saved views, incident artefacts and exports should record these settings so another person can understand whether a result came from full-resolution submitted records or the accelerated long-window series.

As AI-assisted analysis expands, the same provenance should accompany machine-generated conclusions. Dataseries selection is part of evidence lineage, not a performance detail that can safely disappear behind a polished answer.

Time slices and replicated shards make history distributable

Current Kentik architecture documentation describes KDE tables as sequences of time slices. Full tables use minute-scale logical slices, while fast tables use hour-scale slices. Each slice is represented by replicated shards placed on different workers.

This arrangement divides a customer’s history into smaller units that can be stored and queried in parallel. A request covering a defined time period can be mapped to the slices relevant to that window rather than treating the entire retained history as one monolithic table.

Time slicing also supports retention management because older units can be handled according to service policy without changing the conceptual model of newer records.

Replication across workers improves availability, but the public logical description does not reveal the complete durability model. It does not by itself establish rack, zone or regional separation, recovery coordination, consistency behaviour during failure or the total number of physical copies.

Those are operational properties beyond the published table model and should remain unstated unless independently documented.

Slice duration should not be confused with the precision of every returned measurement. A logical one-minute or one-hour storage slice describes organisation of the data. Source records may already be sampled, aggregated or timestamped at a different resolution, while queries can group results into broader intervals.

Even with those qualifications, the design explains much of KDE’s commercial logic. Historical network evidence becomes manageable by dividing it along time, replicating it across workers and making the relevant units addressable in parallel.

Master and worker nodes turn one question into distributed work

When KDE receives a query, master nodes identify the relevant time slices and workers holding the required shards. The query can then be divided into subqueries, executed across workers and reassembled into one result.

That distribution is invisible to most users, but it makes query design consequential. A request limited to selected devices, native dimensions and a defined time window can target a narrower set of data. An all-devices query across a long period with complex derived dimensions asks the system to coordinate more work.

Kentik guidance around device selection and precomputed recurring tags reflects this execution model. These are not only interface suggestions; they change the amount of computation required.

The columnar design also suits the dominant workload. Many network questions aggregate a small number of dimensions across many records: bytes by ASN, traffic by interface, flows by site or volume by provider over time. A column-oriented engine can focus on the required fields rather than reading every property of every record.

The supplied evidence supports Kentik’s description of KDE as columnar, but it does not provide independent benchmark results or enough implementation detail for a defensible performance comparison with other analytical engines.

Distributed coordination also creates its own dependencies. A master needs an accurate view of shard availability. Workers need compatible schemas. Tags and mappings have to be interpreted consistently across the selected period. Supported APIs and rate limits shape repeated automation.

Public documentation explains the logical execution path rather than every scheduler, cache, admission-control or recovery mechanism. Those details should not be inferred simply because the high-level architecture is known.

For customers, the practical point is that performance and analytical meaning are connected. A broad query is not always merely a slower version of a narrow one if the broader query crosses different devices, dataseries or enrichment paths. Good analysis begins by defining the right evidence set.

BGP enrichment needs a lineage check before it becomes route evidence

BGP enrichment is one of KDE’s most network-specific capabilities. It lets traffic be grouped by autonomous system, path and related routing attributes, connecting observed volume with control-plane context useful to peering and transit teams.

That can turn retained flow history into questions about providers, customers, destination networks, route changes and interconnection use. It also creates a risk that a convenient ASN or path field is treated as more authoritative than its source allows.

Kentik documentation indicates that BGP population can depend on whether a device peers with Kentik, whether a peering table contains a matching route and whether path information is available at ingest. When those conditions are absent, some context may be derived from address mappings while path fields remain unavailable.

A populated autonomous-system field therefore should not automatically be read as evidence that the exporter directly observed the complete AS path.

Control-plane evidence also differs from forwarding truth. A BGP route describes reachability learned or selected at a routing point. It does not prove that every packet followed the inferred path, that tunnelling did not change the data plane or that asymmetric routing was absent.

Flow records and routing context can support a stronger explanation together, but each should remain tied to what it actually observed.

Time makes the distinction more important. The route context attached when a record enters the system reflects the route state and mapping available at that time. A later table may differ. Historical analysis benefits from preserving contemporaneous context, yet users need to know whether a value was directly observed through peering, derived from reference mapping or unavailable.

Before a commercial decision such as a peering change or transit negotiation is based on a KDE dimension, the team should verify the source, observation point and timestamp of the relevant routing evidence. KDE can make that evidence queryable; it cannot remove the need to understand how it was created.

The move away from direct SQL changed the customer boundary

Historical KDE material exposed a SQL-like analytical model, including PostgreSQL-style access and Query SQL examples. Current Kentik documentation says Query SQL and direct PostgreSQL access were deprecated as of 1 May 2025.

Supported interaction now centres on Kentik’s portal and APIs. The shift changes how much of the datastore customers interact with directly.

For customers that built bespoke SQL workflows, a deprecation can create migration work, reduced flexibility or stronger dependence on vendor-defined query contracts. Historical examples that rely on direct SQL should therefore be dated rather than treated as current operating instructions.

Kentik also gains clear benefits from the change. APIs can provide stable product abstractions, enforce safer request patterns, apply authentication and rate controls, and allow the underlying implementation to change without exposing every internal detail.

The portal can present network-specific dimensions and guided workflows without requiring users to understand table design. From a product perspective, the data engine becomes more clearly a managed service substrate rather than a database customers operate against as though it were their own.

That convenience brings a governance question. Once analytical logic moves behind supported APIs, product design helps determine which queries are easy, expensive or no longer possible. API versioning, export capability and schema continuity therefore become part of customer risk.

An API can be easier to automate than ad hoc SQL while still creating lock-in if it cannot reproduce historical analyses or provide enough of the underlying evidence to rebuild them elsewhere.

The 2025 change is therefore more than a technical deprecation. It illustrates Kentik’s evolution from a database-like interface towards a governed operational platform. Buyers should evaluate not only current dashboards, but also the durability of APIs, export rights and the cost of rebuilding integrations after another interface change.

Applications around KDE translate stored evidence into operating work

Most customers do not buy a distributed columnar datastore as an end in itself. They buy the ability to investigate traffic, capacity, cloud paths, customer impact, peering, cost, anomalies and security events.

Kentik’s applications translate KDE dimensions and queries into workflows aligned with those responsibilities. The flow-analytics lineage remains visible in traffic and capacity views. Device-monitoring products add interface and system state. Synthetic testing adds controlled probes. Cloud integrations add provider-defined flow logs and resource context. Routing and market-intelligence products add broader path and network views.

Alerts and AI-assisted functions sit above the same broader evidence environment. The expansion gives users a shorter path from observation to an operational question.

It does not mean every application is backed by identical data with identical retention. A synthetic test is generated evidence, not a customer flow record. A device counter comes from a different collection path. A market-intelligence view may use public or platform-wide information distinct from a customer’s private telemetry.

The platform can correlate these layers while preserving their meanings. An article should not imply that every application writes the same record type into one universal table or that every dataset shares one tenancy and retention policy.

The benefit of packaging is accessibility. A network team can move from an alert to traffic dimensions, compare route or interface context and widen the time range without building a new analysis pipeline. People who do not write database queries can still use specialist evidence.

The cost is abstraction. Sampling, aggregation, dataseries selection and field provenance can disappear behind a convenient dashboard. The more the interface recommends a conclusion, the more important it becomes that users can inspect the supporting records and assumptions.

KDE succeeds as a platform substrate when applications make network evidence easier to use without making the evidence look more complete than it is.

Service providers can connect traffic evidence with commercial structure

For a service provider, traffic volume is inseparable from commercial relationships. Bytes cross customer ports, private interconnects, settlement-free peers, paid transit and backbone paths with different costs and responsibilities.

KDE can group retained flow evidence by interface, autonomous system, provider, site, path and customer-defined dimensions. This gives peering and capacity teams a shared analytical base for questions that otherwise require several systems.

A provider can investigate whether growth belongs to one customer, one content network or one destination region. It can compare interconnect utilisation over time, look for a routing change near an incident and assess where capacity may be needed.

DDoS workflows can use flow patterns and routing context to identify unusual volume and affected services. That remains different from packet-level forensic attribution or a complete security investigation.

The engine does not decide the commercial answer. A high-volume relationship may be strategically valuable or expensive depending on contracts, geography and alternatives. An ASN mapping does not reveal a private agreement. BGP evidence can be incomplete. Sampling can distort small traffic classes.

Kentik makes the relevant history easier to query. The interpretation still belongs to people who understand the network and its contracts.

Long retention is particularly useful in planning and negotiation because it replaces isolated peak screenshots with a sustained record. That record is credible only if exporters and metadata remain consistent. A customer rename halfway through a quarter or an interface reassignment without a corresponding metadata update can fragment the history.

Operational discipline upstream of KDE therefore determines whether the commercial narrative built from the datastore is coherent.

Enterprises use the same engine across WAN, cloud and application context

Enterprise networks produce a different set of questions. Teams want to know which site or cloud region generated traffic, whether a path change affected an application, how a migration changed egress cost or whether an unexpected destination belongs to approved business activity.

Custom dimensions, cloud context, device telemetry and synthetic evidence can connect those questions across environments that would otherwise be monitored separately.

Cloud telemetry is important precisely because an enterprise may not control the physical router at every observation point. Provider flow logs and metadata extend visibility into virtual networks, gateways and regions.

Their schemas and capture semantics differ by provider. A cross-cloud comparison therefore needs documentation rather than an assumption that one field has identical meaning everywhere.

For SRE and application teams, KDE can add a network narrative to a service incident. Traffic, routes, interfaces and synthetic tests can show whether the network changed around the same time as an application symptom.

The engine is not an application tracing platform and cannot explain code, database or service-dependency failures on its own. Its value is to make the network contribution easier to test rather than to replace adjacent observability systems.

Cost analysis also depends on business metadata. Sites, teams, applications and cost centres need stable tags before usage can be allocated credibly. KDE can calculate against those categories, but it cannot decide which organisation should own them or resolve disputes about cost responsibility.

A cost dashboard is only as sound as the tagging and pricing assumptions beneath it.

Alerts and AI can prioritise evidence without turning it into truth

Alerting moves KDE from retrospective query towards continuous operational attention. Policies and models can identify unusual traffic, thresholds, path changes or deviations from an expected baseline.

The main value is speed. A network operator can be directed towards a relevant slice of history before a user report or a monthly review reveals the problem.

Every alert still contains assumptions. Seasonality, maintenance, incomplete collection or a changed workload can distort a baseline. One threshold can be too broad for one site and too sensitive for another. Enrichment errors can point the investigation at the wrong customer, region or application.

False positives create fatigue. A narrow model can miss an event that falls outside its learned pattern. Retained history helps analysts test the alert, but it does not make the alert self-validating.

AI-assisted investigation adds another reasoning layer above the same evidence. Its value depends less on fluent prose than on whether the system selects the correct time window, devices, dataseries and dimensions.

A useful answer should let an operator move back from the narrative to the filters, records and context that support it. Without that traceability, a plausible explanation can outrun the data.

The risk increases when advice becomes action. A mistaken diagnosis is inconvenient; an automated routing, firewall or capacity change can create a broader outage. High-impact workflows need confidence thresholds, deterministic checks, approval and rollback.

The existence of a large telemetry store does not remove the need for change governance. It increases the importance of knowing which evidence caused the change.

Security and privacy depend on controls beyond the table diagram

KDE can contain sensitive operational material even without packet payloads. Long histories of addresses, traffic relationships, interface names, customer labels, cloud topology, routing context and security events can reveal business and network structure.

Kentik publishes trust and privacy material, and its architecture documentation supports the claim that customer flow records are logically separated. Those sources do not publicly describe every detail of physical isolation, encryption, key management, privileged access, replication geography, residency or incident history.

Customers therefore need the applicable security reports, contracts and controls rather than assumptions derived from a high-level product diagram.

Retention creates a direct trade-off. More history can strengthen investigations, trend analysis and planning. It also increases the volume of sensitive data exposed to unauthorised access, residency requirements and deletion obligations.

The appropriate retention period depends on operational need, price and risk. “More data” is not universally better if the organisation cannot govern it.

Export is part of resilience as well. A customer that depends on KDE as incident memory should know how records, tags, saved analyses and derived context can be retrieved if pricing, contracts or ownership change.

An API can provide access without guaranteeing practical portability of the complete analytical history. The SQL deprecation makes this question more important because supported access is increasingly mediated through Kentik’s interfaces.

The pending acquisition adds another governance layer. If the Infoblox transaction closes, customers will need clarity on controller roles, system integration, data sharing, residency and cross-product use. Until those details are published, the defensible statement remains that the companies proposed a combined operational data fabric.

Kentik’s financing explains investment capacity, not KDE’s economics

Kentik raised substantial private capital as it developed the platform. The source record includes about $3.1 million of early seed financing, a $23 million Series B, $23.5 million of growth funding and a $40 million Series C.

Kentik said cumulative financing had reached about $102 million after the 2021 Series C.

Those numbers help explain how the company funded engineering, infrastructure, product expansion and go-to-market activity. They do not disclose how much capital went into KDE, how much storage and query execution cost, which product lines generate revenue or whether the company was profitable.

No standalone KDE revenue, cost base, valuation or margin is available in the supplied evidence.

The economics of the engine can nevertheless be understood at a mechanism level. High-volume ingest, replicated storage, long retention, contextual enrichment and distributed queries all consume infrastructure.

The existence of a fast dataseries reflects part of that reality: scanning full-resolution high-cardinality history across long periods can be expensive, so the architecture provides a different analytical path for broader windows.

The actual cost model remains private. Pricing and retention therefore have to be evaluated through the commercial service, not inferred from the architecture.

Private-company opacity also limits broader comparison. The source record does not provide audited public accounts showing customer concentration, renewal rates, cash flow or profitability.

Financing announcements establish money raised and product direction. They should not be turned into financial performance claims.

For buyers, commercial diligence is better focused on observable contract terms: retention, ingest limits, export, API access, support, service commitments and protections against material product changes.

A large funding total can show past access to capital. It cannot guarantee future pricing, product continuity or the outcome of an acquisition.

The Infoblox agreement could change the engine’s strategic role

On 8 July 2026, Infoblox announced a definitive agreement to acquire Kentik. The announcement presented the proposed combination as a way to unite authoritative DNS and asset visibility with network observability, including flow, path, cloud, synthetic and device telemetry.

The companies described an ambition to create a richer operational data fabric that could support more automated workflows.

At the source cutoff, the transaction had not closed. It remained subject to approvals and customary closing conditions. Kentik therefore remained the operator and owner of KDE at that point.

Describing KDE as an Infoblox product before closing would turn an announced transaction into a completed fact. The same caution applies to the proposed combined data fabric: strategic intent is not the same as a shipping integrated product.

If the acquisition closes, the technical fit is understandable. Infoblox’s DNS, DHCP and IP address management systems can contribute identity and asset context that flow data often lacks. Kentik can contribute traffic volume, paths and network evidence that DDI systems do not provide on their own.

A well-governed join could help an operator move from an address to a device, owner, DNS activity, observed traffic and path involved in an incident.

The integration challenge is equally clear. Identity changes. DHCP leases expire. DNS names are reused. Addresses are translated. Assets move. Flow records arrive from different observation points.

Product teams would need to decide which system is authoritative for each field, how timestamp conflicts are handled and how users inspect the lineage of combined data.

A unified data fabric that hides disagreement can create more confidence than the evidence deserves. Two systems with explicit boundaries can be safer than one model that silently resolves conflicts.

Commercial decisions will follow the technical work. Infoblox could preserve Kentik as a specialist platform, consolidate interfaces, change packaging or integrate products in stages. APIs, retention, pricing and organisational responsibilities can change after closing.

None of those outcomes was established by the announcement. The responsible position is to describe the strategic logic and wait for legal completion and product evidence before reporting implementation.

KDE competes as a network-specific system, not only as a database

Kentik operates in a market that includes purpose-built flow analytics, broader observability platforms and do-it-yourself stacks built from general data systems.

Commercial alternatives can include Cisco Secure Network Analytics, Plixer Scrutinizer, ElastiFlow and Datadog Network Performance Monitoring, among others with different product scopes. Open and general-purpose analytical tools can also become substitutes for organisations prepared to build more of the network model themselves.

ClickHouse, Druid, BigQuery or Snowflake may serve as analytical substrates. Grafana and Prometheus ecosystems can provide metrics and dashboards. Packet capture provides richer forensic detail at much higher storage and privacy cost. Public BGP collectors provide control-plane evidence without a customer’s private flow history.

A database benchmark alone therefore cannot settle the comparison. KDE’s value includes collectors, field models, routing and GeoIP enrichment, dual dataseries, packaged workflows, alerting, APIs and support.

A general analytical engine may perform well for one workload while still requiring substantial engineering before it answers a peering, capacity or network-cost question.

The purpose-built model packages those semantics and workflows. The customer pays for that packaging through vendor dependence and lower implementation transparency.

Packet capture is richer than flows for some forensic questions and much more expensive to retain. Public BGP platforms are valuable for external routing evidence but cannot reconstruct one operator’s private traffic. Metrics systems are strong for counters and health while being less suited to high-cardinality traffic relationships. A SIEM can correlate security events without becoming a network-economic analytics platform.

Each alternative changes what is observed, what is retained and who is responsible for operating the data system.

KDE’s structural advantages are network-specific dimensions, retained history, routing enrichment, schema flexibility and integrated applications. Its structural disadvantages include proprietary opacity, dependence on source quality, lack of public independent performance benchmarks, interface lock-in and uncertainty around the pending acquisition.

The commercial choice is therefore also a choice about responsibility. Buying Kentik transfers much of the collection, storage and analytical engineering burden to a specialist vendor. Building internally preserves more control while making the customer responsible for collectors, schema, queries, upgrades and failure recovery.

The engine cannot know what its sources never observed

KDE’s most important limit is not storage capacity. It is epistemic. The engine can preserve, enrich and correlate observations. It cannot recover packets excluded by sampling, fields omitted by an exporter, a route absent from the available BGP context or a cloud event outside the provider’s logging boundary.

A precise query over incomplete evidence remains incomplete.

Some gaps are obvious. A path field is empty. An exporter stops sending. A device is missing. Other errors are harder to see. A GeoIP mapping looks plausible and is wrong. Two observation points count related traffic. A fast-series trend obscures a small traffic class. A stale interface description assigns usage to the wrong customer.

A dashboard can look internally consistent because every component inherited the same incorrect tag.

The proprietary implementation creates another boundary. Public documentation describes databases, dataseries, slices, shards, workers and masters, but not the complete physical topology, node count, storage volume, scheduling algorithms, tenant-isolation design or independent performance results.

The logical model is documented more clearly than the physical and economic model. That is normal for a managed commercial service, but it means analysts should not turn a logical diagram into claims about controls it does not describe.

AI can make these limits easier to overlook by converting partial data into fluent conclusions. The useful response is not to reject automation, but to make evidence lineage part of the answer: source, time, observation point, dataseries, resolution, enrichment method and confidence.

Operators should be able to move from a recommendation back to the evidence that supported it.

KDE is therefore best treated as a decision-support datastore rather than a self-sufficient source of truth. Its strength is retaining and connecting distributed observations across time. Its discipline lies in preserving the difference between correlation and certainty.

A useful network memory must preserve uncertainty as carefully as data

Kentik Data Engine changes the practical unit of network analysis. Instead of asking only what one device shows now, an operator can ask what many observation points recorded over a defined period and group the result by routes, geography, interfaces, providers and business context.

Distributed columnar storage, multiple dataseries and parallel query execution make that history usable through a managed platform.

The same architecture can produce false certainty if its conditions are hidden. “Full” can be mistaken for every packet. An ASN can be mistaken for a directly observed path. A customer database can be mistaken for dedicated physical infrastructure. A fast query can be mistaken for the same evidence at full resolution. An acquisition agreement can be mistaken for completed ownership.

Each error collapses two layers the evidence keeps separate.

The longer-term significance lies in the movement from observability towards operational automation. A retained and contextual network history is the kind of substrate on which alerting and AI systems can reason.

The better the history, the more useful the recommendation. The more consequential the action, the more important it becomes to expose where the data came from and what the collection system could not see.

KDE does not turn flows into decisions on its own. Exporters create observations. Collectors ingest them. Universal Data Records map fields. Enrichment adds context. Dataseries preserve different analytical resolutions. Masters and workers execute queries. Applications present results. People or governed workflows decide what to do.

The value lies in that complete chain. Removing the limits from the explanation turns an evidence system into a marketing claim.