Datastreams
    Datastreams versus hyperscaler data stacks

    From cloud building blocks
    to one serviced business runtime.

    AWS and Google Cloud offer powerful components for almost any architecture. The trade-off is ownership: your organisation or its consultants must assemble, secure, monitor and change the complete operation. Datastreams starts with that complete governed operation and runs it on one declarative runtime.

    Product capabilities and packaging change. This comparison was reviewed against official vendor documentation on 6 September 2026; validate the current fit during procurement.

    The short answer

    The overlap is a feature. The difference is the foundation around it.

    Hyperscalers provide specialised building blocks that can be assembled into almost any architecture. Datastreams provides the complete operating foundation directly. The comparison is therefore not one runtime against one cloud service, but one runtime against the service chain and implementation work required for the same operation.

    Choose AWS or Google Cloud when

    • You have a mature cloud platform team and need bespoke infrastructure or services beyond the Datastreams runtime boundary.
    • Independent scaling, tuning and replacement of every infrastructure component is a deliberate requirement.
    • The organisation accepts provider-specific IAM, observability, billing and operational models as part of its architecture.

    Choose Datastreams when

    • The desired outcome can be expressed as sources, quality, state, rules, permissions, actions and destinations.
    • The organisation wants a complete standard operation on one server instead of owning the integration between messaging, processing, storage and governance services.
    • Deployment choice and portability matter, and data should not be stored merely because the reference stack assumes a lake or warehouse.

    Decision matrix

    Datastreams and AWS or Google Cloud, compared by operating need.

    This is an architectural comparison, not a feature-count contest. The right choice depends on the operation the organisation must own.

    Starting point

    AWS or Google Cloud

    Independent cloud infrastructure and platform services that a customer or consultancy composes into a solution.

    Datastreams

    One purpose-built runtime in which complete data and event operations are declared.

    Decision lens

    Compare the finished operating architecture, not an individual cloud component with the runtime.

    What is bought

    AWS or Google Cloud

    Composable infrastructure services for messaging, compute, storage, analytics, IAM, monitoring and many adjacent needs.

    Datastreams

    One serviced runtime for complete declared business data operations.

    Decision lens

    Building blocks maximise freedom; an integrated runtime minimises assembly.

    Typical flow

    AWS or Google Cloud

    AWS reference architectures combine services such as MSK or Kinesis, Lambda or Glue, Firehose, S3, Redshift, monitoring and BI. Google describes Pub/Sub with Dataflow and BigQuery, with simpler direct subscriptions for narrower cases.

    Datastreams

    One runtime validates, calculates, maintains required state, decides and distributes to selected endpoints.

    Decision lens

    Count the services actually required, including monitoring, recovery and security around each boundary.

    Starting topology

    AWS or Google Cloud

    Processing is assembled across selected managed services, each with its own service boundary and operational model.

    Datastreams

    The complete standard data-in-motion operation can run as one runtime on one server.

    Decision lens

    Add nodes only where workload, availability or recovery requirements justify them.

    Business rules

    AWS or Google Cloud

    Implemented in application code, SQL, functions, stream jobs, templates or several service configurations.

    Datastreams

    Kept as a versioned declarative model separate from event payloads and endpoint integrations.

    Decision lens

    Ask whether the business can inspect the operation without reconstructing cloud code.

    Data quality

    AWS or Google Cloud

    Built using schemas, processing jobs, catalogues, validation code, monitoring and exception destinations selected by the team.

    Datastreams

    One quality contract gates every delivered output and gives exceptions an explicit path.

    Decision lens

    Cloud services provide the primitives; the customer owns the complete quality system.

    Storage

    AWS or Google Cloud

    Many reference paths land streams in S3, BigQuery, Redshift or other stores, although both clouds also support direct or alternative patterns.

    Datastreams

    Storage is optional when data can be processed and delivered while moving; add only the state, history and evidence required.

    Decision lens

    Avoid paying and governing a central copy when the business outcome does not need one.

    Operations

    AWS or Google Cloud

    The customer owns service selection, IAM, networking, quotas, observability, cost controls, upgrades and cross-service incident diagnosis.

    Datastreams

    Datastreams services the runtime under an explicit operational and deployment agreement.

    Decision lens

    Include people, specialist skills and cross-service change in total cost.

    Runtime-first architecture

    The capabilities others connect around an endpoint are already runtime responsibilities.

    A general cloud stack allocates resources by service boundary: message transport, processing jobs, functions, temporary or durable storage, warehouse ingestion, monitoring and networking may each meter work and retain their own operational state. Datastreams can remove intermediate transport and storage when one runtime performs the complete operation on the event. This reduces architectural surface and often the resources that accompany it, but only a like-for-like workload benchmark can quantify the saving.

    A standard Datastreams deployment can run the complete declared operation on one server. That can replace several functional service boundaries and the integration work between them; it does not mean every production topology is always one machine.

    Actual compute, memory, storage and network use depend on event volume, state, rules, destinations, availability and recovery requirements. Redundancy or exceptional workloads can require additional nodes. We compare an agreed workload and topology before making a numeric saving claim.

    Primary sources

    Read the vendor documentation behind this comparison.

    We link to product-owned documentation rather than relying on review sites or anonymous feature tables.

    AWS: Modern streaming architecture patterns

    Official reference patterns combining streaming, functions, processing, storage, warehouse, search and analytics services.

    Open official source

    AWS: Glue streaming sources and targets

    Official supported streaming inputs, processing model and data targets.

    Open official source

    Google Cloud: Pub/Sub

    Official positioning of Pub/Sub with Dataflow, BigQuery, storage and operational destinations.

    Open official source

    Google Cloud: Dataflow streaming analytics

    Official real-time ETL and integration paths, templates, custom transforms and output systems.

    Open official source

    Google Cloud: Direct Pub/Sub to BigQuery

    Official acknowledgement that a direct path can simplify architecture and billing when Dataflow transformation is unnecessary.

    Open official source

    Compare the architecture around one operation you actually run.

    Bring the current services, data movements, quality rules, destinations, operational work and costs. We will map the equivalent Datastreams boundary and identify what would remain.

    Start an evidence-based comparison