Frequently Asked Questions
Product & Architecture
What is Krenalis?
Krenalis is a warehouse-native Customer Data Platform (CDP) built for teams that want full control over their customer data infrastructure. It runs inside your own environment and operates directly on top of your existing data warehouse.
Krenalis unifies customer events and profiles into a reliable, strongly typed unified profile (often referred to as a "golden record"). It activates that data in near real time across analytics and engagement tools, without copying customer data into a separate SaaS platform.
Because it works directly on warehouse data, Krenalis aligns with how modern data teams already build and operate infrastructure.
In practice, this means:
- Customer events and profiles remain in your warehouse (zero-copy architecture)
- Identity resolution is deterministic, reversible, and fully configurable
- Data governance, access control, and compliance follow your existing warehouse policies
- Krenalis can coexist with existing event pipelines during gradual migrations
How does Krenalis differ from traditional CDPs?
Traditional CDPs typically collect and process customer data inside their own cloud infrastructure, creating a separate data layer outside your warehouse.
Krenalis takes a different approach. It runs directly on top of your existing data warehouse, so events, profiles, and identity resolution remain inside your infrastructure.
This architectural difference has practical implications if you are building and operating customer data infrastructure:
- No duplication of customer data into a third-party SaaS environment
- Full control over schema design, transformations, and identity resolution logic
- Cost scaling tied to your warehouse infrastructure rather than event-based pricing tiers
- Compliance and access control aligned with your existing data governance policies
Can we replace Segment or RudderStack with Krenalis?
Yes. Krenalis can replace Segment or RudderStack for teams adopting a warehouse-native, self-hosted architecture.
Krenalis implements the same event tracking protocol used by Segment and RudderStack. In standard tracking setups, existing SDKs and tracking calls continue to work without requiring a full re-instrumentation of your applications.
Krenalis can also be configured as a destination for events forwarded by Segment or RudderStack. This allows you to stream your current event flow into Krenalis, validate unified profiles and identity resolution behavior, and transition progressively without disrupting production systems.
Because Krenalis operates directly on top of your warehouse, it can coexist with your current pipeline during migration.
- Gradual migration of event ingestion
- Parallel validation of unified profiles
- Incremental replacement of activation pipelines
Teams typically validate on a focused scope before expanding coverage.
How scalable is Krenalis?
Krenalis scales with your underlying data warehouse. It does not impose artificial event caps or tier-based limitations.
Because events, profiles, and identity resolution operate directly on your warehouse, scalability depends on the compute and storage capacity you provision (e.g., PostgreSQL or Snowflake).
In practice, this means you scale Krenalis the same way you scale the rest of your data stack:
- Handle high-volume real-time event ingestion
- Run identity resolution without exporting data to external systems
- Leverage your existing indexing, partitioning, and query optimization strategies
- Align cost scaling with infrastructure decisions rather than event-based pricing tiers
How does Krenalis handle data privacy and compliance?
Krenalis is built on a simple architectural principle: customer data remains in your infrastructure.
Events, profiles, and identity resolution operate directly on your existing data warehouse. Krenalis does not introduce a separate vendor-hosted storage layer for core CDP data.
In practice, this means:
- Data access follows your existing role-based access control and security policies
- Backups and disaster recovery remain aligned with your warehouse procedures
- No additional external data processor is introduced for primary data storage
- Optional AI querying features can be configured with read-only credentials
Krenalis is developed by a European company and is commonly evaluated by organizations operating under GDPR and other strict regulatory frameworks. Its self-hosted architecture keeps primary customer data within systems already governed by your internal compliance processes.
Licensing & Customization
What is its Licensing approach?
Krenalis follows a dual-licensing model designed to encourage adoption while protecting long-term product sustainability.
The core platform is released under the Elastic License v2. This allows you to use, modify, and deploy Krenalis internally within your own infrastructure, while preventing it from being offered as a managed SaaS service to third parties.
In practice, this means you can run Krenalis in production, adapt it to your internal requirements, and integrate it deeply into your stack without being locked into a proprietary black box.
Connectors and data warehouse drivers are released under the MIT license, which allows broad use, modification, and redistribution. You can build custom connectors or extend existing ones without licensing constraints.
For organizations that require contractual guarantees, prioritized support, or dedicated development, commercial agreements are available alongside the source-available model.
Can I customize or extend Krenalis?
Yes. Krenalis is designed to be adapted to your existing data architecture rather than forcing you into a fixed workflow.
You can modify data models, adjust identity resolution logic, and extend pipeline behavior to match your internal requirements. Connectors and warehouse drivers can be extended or built from scratch to integrate internal tools or third-party systems.
- Build custom connectors for internal or external systems
- Define and evolve identity resolution rules based on your business logic
- Extend transformations using JavaScript or Python
- Integrate Krenalis into CI/CD and infrastructure automation workflows
For organizations requiring additional guarantees or dedicated integration support, commercial agreements are available.
Who is it for?
Krenalis is designed for technical teams building customer data infrastructure on modern data warehouses. It is not designed as a no-code marketing automation tool.
It is a strong fit for organizations that want their CDP to behave like the rest of their data stack, not like a separate marketing tool.
In practice, Krenalis works particularly well for:
- Companies already using PostgreSQL or Snowflake as their primary data warehouse
- Organizations that want full control over identity resolution logic and profile structure
- Organizations that prefer on-premises or self-hosted deployment models
- Organizations evaluating alternatives to usage-based, vendor-hosted CDPs
If you are comfortable managing warehouse infrastructure and value architectural control over feature gating, Krenalis is likely aligned with how you build software.
When is Krenalis not the right fit?
Krenalis is designed for teams that operate their own data infrastructure. It is not intended to replace fully managed, vendor-hosted CDPs for organizations that prefer a pure SaaS model with no infrastructure responsibility.
It may not be the right fit if:
- You do not operate a data warehouse or do not plan to manage one
- You are looking for a no-code marketing automation platform rather than an infrastructure-level CDP
- You prefer usage-based pricing tied to event volume instead of infrastructure-based cost control
- Your team does not have engineering resources to manage deployment and warehouse operations
Krenalis works best when customer data is treated as a core part of your data stack rather than as a separate marketing layer.
Commercial & Production
What kind of support and documentation is available?
Krenalis provides detailed technical documentation covering installation, configuration, identity resolution, integrations, and production deployment.
The documentation is designed for engineers and includes architecture explanations, configuration examples, and integration guides so teams can understand how Krenalis fits into their existing warehouse setup.
If you get stuck, documentation is the first stop, and support can help you unblock quickly when needed.
Commercial customers work directly with core engineers, not a tiered support desk:
- Severity-based response times
- Immediate escalation for production-critical issues
- Dedicated Slack channel and direct email access
- Prioritized fixes when required for production stability
Since Krenalis runs inside your infrastructure, warehouse-level concerns such as backups, scaling, and disaster recovery follow your existing operational policies. Our team focuses on configuration, integration, and resolving application-level issues to ensure stable production deployments.
Is Krenalis production-ready?
Yes. Krenalis is production-ready and actively used in live customer environments.
The platform has evolved over more than three years of architectural iteration and real-world validation, with a strong focus on building a robust warehouse-native foundation before general availability.
Krenalis is designed to operate reliably within modern data infrastructures, leveraging your existing warehouse for storage, compute, backups, and disaster recovery. It does not introduce a separate vendor-managed data layer that would require additional governance.
Commercial customers work directly with the core engineering team during deployment and ongoing operations. Critical issues receive immediate escalation, and fixes are prioritized to ensure stable production environments.
As with any infrastructure component, we recommend starting with a focused rollout to validate performance, identity resolution logic, and operational fit within your specific warehouse setup before expanding coverage.
Which data sources and destinations are supported?
Krenalis supports a growing set of SDKs, databases, file formats, storage systems, and SaaS integrations.
It is designed to work with modern event tracking setups and warehouse pipelines, so teams can integrate it without rebuilding their entire data flow.
Supported sources and destinations currently include:
- Event collection SDKs such as JavaScript, Go, Node.js, Python, Java, .NET, iOS and Android
- Databases including PostgreSQL, MySQL, Snowflake, and ClickHouse
- File formats such as CSV, JSON, Parquet, and Excel
- File storage systems including S3, SFTP, HTTP endpoints, and local file systems
- SaaS platforms such as HubSpot, Klaviyo, Mailchimp, Mixpanel, PostHog, Stripe, Google Analytics, and other marketing or analytics tools
You can integrate Krenalis alongside your existing tracking and activation stack, gradually expanding coverage over time. You can find the most up-to-date list of integrations in the integration documentation.
How can we evaluate and get started with Krenalis?
Krenalis can be deployed in a staging or test environment so you can evaluate the architecture, identity resolution logic, and integrations before committing to a full production rollout.
Most teams begin with a focused proof of concept built around one or two concrete use cases. This keeps the evaluation practical and aligned with real business requirements.
A typical evaluation looks like this:
- Deploy Krenalis in a non-production environment
- Connect one event source and one destination
- Define a minimal unified profile and identity resolution setup
- Validate end-to-end data flow, performance, and operational fit with your warehouse
Once validated, you can progressively expand coverage across additional sources, destinations, and profile definitions.
There is no rigid evaluation framework or long-term commitment required. If helpful, the team can support you in scoping a pilot aligned with your timeline and infrastructure constraints.
Comparison
| Feature / Product | Krenalis | Segment | RudderStack |
|---|---|---|---|
| Deployment Model | On-Premises (self-hosted) | SaaS | SaaS |
| Data Storage & Processing | Customer-hosted storage and processing | Vendor-hosted storage and processing | Customer-hosted storage, vendor-hosted processing |
| Data Architecture | Warehouse-native, zero-copy | Cloud-hosted architecture | Warehouse-native, zero-copy |
| Event Ingestion | Yes, real-time, device mode support | Yes, real-time, cloud-mode | Yes, real-time, device-mode |
| Profile Batch Ingestion (ETL) | Yes. From apps, databases, files | No | No |
| Schema Validation | Strongly typed unified profile (golden record) | Ingestion-only | Ingestion-only |
| Transformations | Visual mapping, JavaScript, and Python | Visual mapping | JavaScript and Python (Python varies by plan) |
| Warehouse Sync Time | Near real-time (warehouse-native) | Plan-dependent (hours) | Plan-dependent (minutes to hours) |
| Identity Resolution | Yes, deterministic, reversible, lossless | Yes, deterministic, non-reversible (requires Customer Data Platform plan) |
Yes, deterministic, reversible, lossless (requires Enterprise plan + Profiles) |
| Activation (Reverse-ETL) | Yes (events and profiles) | Available with a custom quote | Available with a custom quote |
| Core License | Elastic 2.0 | Proprietary (SaaS) | Proprietary (SaaS) |
| Connectors License | MIT (Open Source) | MIT (Open Source) | Elastic 2.0 |
| Pricing | Source-available (commercial support available) | Usage-based / Custom quote (free plan, non-full CDP, available) |
Usage-based / Custom quote (free plan, non-full CDP, available) |
Note: RudderStack offers a self-hosted edition. However, full CDP capabilities may vary by plan and deployment model. The comparison above reflects the primary SaaS offering.