Pub/Sub for AI: The New Requirements for Real-Time Data

AI systems increasingly depend on real-time pub/sub, MQTT event streams, and immediate access to fresh data—especially at the edge. From detecting fraud in financial transactions to spotting anomalies in industrial equipment to powering dynamic personalization, modern models must react to events in milliseconds, not seconds.

But today’s architectures force teams to glue together separate systems: an MQTT broker, a message queue, a feature store, a database, an API layer, and a replication engine. Every boundary introduces latency, inconsistency, and operational overhead. These problems become existential when deploying AI at the edge or across unstable networks.

Harper takes a different approach: it unifies pub/sub, MQTT, WebSockets, SSE, storage, replication, and vector search directly inside the database, creating a real-time platform purpose-built for AI.

This article explores why edge AI requires a new data architecture, why legacy pub/sub systems fall short, and how Harper transforms tables into real-time event streams that replicate globally in 50–100 ms.

‍

AI Needs Real-Time Infrastructure, and Today’s Stack Isn’t Built for It

AI is moving from dashboards to decisions. Models are no longer grading what happened yesterday; they’re deciding what to do now.

How that plays out:

Predictive maintenance

Industrial assets stream high-frequency vibration and temperature data. Edge AI systems are expected to catch anomalies and trigger interventions in milliseconds, not minutes, as factories adopt predictive maintenance to avoid costly downtime.

Fraud detection

Card networks already run fraud scoring in about 50 ms per transaction, and research shows most real-time fraud systems operate at millisecond latency. Every extra round-trip risks either blocking a good customer or letting fraud through.

Personalization

Modern sites stream clickstream data into real-time pipelines so recommendations can update in seconds as users browse. If features lag behind behavior, relevance — and revenue — drop fast.

The common requirement

Across use cases, the bar looks similar:

• Low latency for decisions on fresh events
• Durable state feeding models
• Reliable replication across sites
• Operation during network interruptions
• Multiple protocols feeding the same system
• Edge-local inference that runs without cloud in the hot path
  
  

The problem: today, this is assembled from MQTT brokers, Kafka clusters, databases, sync layers, edge gateways, and more. Guides for building predictive maintenance or fraud platforms all assume a patchwork of services. It works, but only because teams pour time into stitching it together.

We need an architecture where real-time isn’t an add-on, it’s the default.

‍

Cloud Deprecations Exposed the Cracks

Cloud-managed IoT and event services have given teams a harsh lesson in platform risk:

• Google’s Cloud IoT Core was retired on August 16, 2023, with device connections to its HTTP and MQTT bridges shut down after that date.
• AWS IoT Analytics ends support on December 15, 2025; after that, its console and resources will no longer be accessible.
  AWS IoT Events ends support on May 20, 2026, with access to its console and resources disabled after the deadline.
  
  

These services weren’t fringe tools, they sat in the middle of industrial IoT, retail telemetry, connected vehicles, and automation. As they were retired, customers were told to rebuild architectures and migrate pipelines on tight timelines, often at their own expense.

That exposes a fundamental truth: critical real-time and edge systems cannot depend on cloud services that can disappear with a product notice and a migration guide.

There’s another crack: hyperscale architectures still assume stable connectivity, an assumption that simply doesn’t hold in the real world. Factories, retail stores, vehicle fleets, and remote installations operate in conditions where networks are intermittent by default. As the Pratexo white paper notes, “intermittent connectivity is a hallmark challenge in edge environments,” especially those operating in remote or mobile contexts where links are “sporadic or unstable.” Systems in these settings must keep operating offline and then re-sync cleanly once connectivity returns—a capability widely cited as a core benefit of edge computing.

Harper is built around one principle: your real-time architecture should run anywhere—cloud, on-prem, or edge—with identical behavior, regardless of which managed services come and go.

‍

The Architectural Reset: Database-Native Pub/Sub

Real-time pipelines traditionally separate the message broker from the database:

• Events go through MQTT, Kafka, or Kinesis
• State lives in a database
• Sync logic glues them together

This creates the notorious “broker/database gap”—a latency and consistency window between the time an event arrives and the time it is durable.

Harper eliminates this gap.

Tables are topics. The database is the pub/sub system.

A record behaves like a retained message:

• Publishing with retain atomically updates the record and notifies subscribers
• Publishing without retain broadcasts ephemeral events
• New subscribers automatically receive the current state from the table

No double-writes. No cross-system sync. No two sources of truth.

State and stream become the same thing.

‍

Replication Designed for the Real World

Replication is the backbone of real-time systems, especially for AI at the edge. Traditional replication is often bolted on, brittle, or outsourced to a broker.

Harper’s replication engine, Plexus, merges the transaction log and replication pipeline into a single fast, efficient system.

Plexus enables:

• Reliable, ordered replication
• Automatic catch-up after disconnects
• Peer-to-peer, self-healing mesh
• Efficient batching + compression
• Selective table or database replication
• Bidirectional or upstream-only sync for tiered edge topologies

Replication typically completes in 50–100 ms, depending on network distance. Same-region deployments often perform even faster.

For AI pipelines where milliseconds matter, this reliability is essential.

‍

Unified Protocol Support: MQTT, WebSockets, SSE

Real-time systems involve diverse clients:

• IoT devices → MQTT
• Browser apps → WebSockets
• Monitoring dashboards → SSE

In legacy systems, each requires a separate backend service.

Harper flips the model:

All protocols subscribe to the same underlying tables.

Integrated support includes:

• MQTT v3.1/v5 with wildcards, QoS 0–1, mTLS, retained messages
• WebSockets with JSON, MessagePack, or CBOR
• SSE for lightweight push streams

Every protocol sees the same state and publishes into the same system.
No routing rules, no protocol-specific brokers, no duplication.

‍

Deploy Anywhere, Run Everywhere

AI doesn’t live in one environment, and real-time systems can’t either. Some workloads run in hyperscale clouds, others in industrial facilities, retail stores, vehicle fleets, or remote sites. The hard part isn’t computing; it’s the inconsistency between environments, where each location demands a different stack, sync model, and operational footprint.

Harper removes that divide.

Whether running on AWS, Azure, GCP, bare-metal servers, or embedded edge devices, Harper behaves the same. The APIs are the same. The pub/sub model is the same. The replication engine is the same.

Your architecture stays portable instead of being tied to a specific cloud vendor or the lifespan of a particular service.

This continuity isn’t just convenient, it’s strategic. When cloud providers retire key services or edge deployments need long-term stability, Harper offers a platform designed to last.

‍

Operational Simplicity Is a Superpower

The modern cloud offers incredible tools, but stitching them together is often where reliability breaks down. Real-time architectures frequently rely on an MQTT broker, a message queue, an event bus, a streaming pipeline, a database, a feature store, and custom glue in between.

Harper replaces this patchwork with a single system.

When pub/sub is native to your database, you don’t synchronize events with state. When replication is built in, you don’t need a separate system to push deltas around the world. When your edge and cloud environments share one data model, you don’t need divergent code paths or fragile sync layers.

Simplicity becomes reliability.
Reliability becomes speed.
Speed becomes a competitive advantage.

And your engineering teams get to focus on what creates value, not on integrating half a dozen services.

‍

A Unified Real-Time Data Layer for the AI Era

As AI moves to the edge and decisions shift from batch windows to milliseconds, organizations need an architecture that treats real-time as the default. They need a system where:

• tables behave like topics
• events and state are one operation
• replication is automatic and resilient
• protocols converge instead of fragment
• deployments span cloud, on-prem, and edge without friction

That’s the world Harper built: applications that react instantly, operate anywhere, and scale globally without the complexity tax of conventional pub/sub architectures.

Harper Pub/Sub isn’t just a feature; it’s the foundation for the next generation of intelligent, distributed systems.

‍

Ready to Build the Future of Real-Time AI?

If you’re exploring real-time pipelines, deploying AI at the edge, modernizing legacy pub/sub systems, or evaluating how to unify your data and streaming stack, now is the time to try Harper.

Spin up a free distributed cluster (no credit card required), subscribe to a table, publish an event, and watch your system respond instantly, anywhere in the world.

‍