The gap between dashboard and data platform
In LATAM there are two legible categories of "data work": cheap BI on top of the ERP at USD 200/month, and an enterprise data platform from USD 300k. Between them runs the market where 95% of the region's growing companies live. This article is about how to cross that boundary without buying Snowflake when ClickHouse was enough, and without hiring a senior data engineer when a four-month contractor would have done.
One scenario. The CFO of an 80-person distributor in Bogotá opens an Excel deck that two analysts spent five business days assembling. The data is from last month — 27 days stale. The Q3 budget decision is today. SKU margin is in dispute: sales says one number, the warehouse says another, finance says a third. He googles data warehouse SMB LATAM and finds either enterprise offers from USD 150k or DIY tutorials for startups "on one server at USD 20/month." In between: nothing.
That gap is the Tier B market for LATAM SMBs. Not Big 4 enterprise. Not Excel-as-database. Mid-market: 50-500 employees, USD 5-100M annual revenue, growing on Odoo, SAP Business One, or NetSuite and simultaneously losing 3-8% of operating margin to decisions made on stale data. For a company with USD 30M in revenue, that is USD 0.9-2.4M per year. A silent, unarticulated tax on the absence of data engineering.
From here: what technically counts as Tier B, how to pick a stack for the LATAM reality, where countries diverge, and where the line falls between "it's time" and "still too early."
One-minute summary
- Tier B ≠ a dashboard on the ERP. It is a separate data warehouse, ELT pipelines, a modeling layer (typically dbt), and a metrics catalog. Tier A is Metabase or Superset over an Odoo Postgres replica.
- LATAM SMB sweet spot: 50-500 employees, USD 5-100M revenue, 3+ isolated data sources, recurring discrepancies across reports.
- Realistic range: first implementation USD 25-80k, monthly run rate USD 300-5,000 depending on the stack. Floor: self-hosted ClickHouse. Ceiling: Snowflake with the regional node in São Paulo.
- Country sensitivity: AR (the FX cap makes USD SaaS 40-60% more expensive), MX (CFDI volumes force a real DW from day one), PE/CL/CO (electronic invoices are a ready-to-ingest source).
- The main mistake: building a DW before fixing source data quality. Garbage in, dashboards out.
- Most teams need a simple stack: dbt + ClickHouse or BigQuery + Metabase or Superset. No Snowflake or Databricks until ML is on the roadmap.
What "Tier B" means in the LATAM context
In the region, the phrase data engineering works as an umbrella that covers everything from "BI for one department" to "a 200 TB Databricks Lakehouse." That ambiguity is the main source of USD 50k checks for work that should have cost USD 5k. The two levels deserve a hard separation.
Tier A — BI on top of the ERP. Metabase or Superset connected to a read-only Postgres replica from Odoo (or NetSuite OData, or a SAP B1 HANA view). Queries run on the same database the ERP uses, or on a copy. Rollout: 1-3 weeks. Monthly run rate: USD 50-250. It works while (a) there is a single source, (b) volumes stay below the million-row mark in the main tables, (c) heavy-query users number ten or fewer.
Tier B — separate data warehouse plus ELT. Data from 3+ sources (ERP, CRM, marketing, warehouse, billing, e-commerce) loads into a dedicated analytical database. On top: dbt models (staging → intermediate → marts), a metrics catalog, BI access through a semantic layer rather than raw SQL. Rollout: 3-5 months to a first usable release. Run rate: USD 300-5,000/month. This is where retention and cohort analysis, cash projections, and near-real-time SKU margin live.
The trigger to move from Tier A to Tier B is usually not "we ran out of Metabase features." It is four specific symptoms:
- Reports for the same metric diverge across departments, because each team builds from its own source.
- Historical accuracy disappears — Odoo overwrites rows when records change, and the business needs snapshot logic for audit.
- Heavy queries block the ERP — the quarterly financial report knocks out the POS.
- Analysts spend 70% of their time on data cleanup instead of analysis.
If three of the four symptoms are present, it is time. Fewer than that and Tier B is an expensive solution to a problem that does not yet exist. For the long read on the underlying problem see the Data Engineering pillar and the companion piece on when BI stops being enough.
Stack for LATAM SMB: real options and real prices
Unlike the US market, where a "modern data stack" starts at Snowflake + Fivetran + dbt + Looker from USD 5,000/month minimum, LATAM mid-market lives in a different pricing reality. Here is the breakdown by configuration, validated across a sample of 30 production projects.
#1. Storage
Self-hosted ClickHouse (Hetzner, DigitalOcean, a local provider in Santiago, Lima, or Bogotá). Cost: USD 250-800/month per instance with 8-32 vCPU, 32-128 GB RAM, NVMe disks. Analytical query speed beats BigQuery and Snowflake on comparable workloads up to 5 TB. Downside: it needs an engineer who knows how to operate ReplacingMergeTree, ReplicatedMergeTree, materialized views, and projections. Best fit for AR and any SMB sensitive to USD spend. Docs at clickhouse.com/docs.
BigQuery is the best pick for LATAM startups and SMBs that already run on Google Workspace and Looker Studio (free). Pricing: USD 6.25 per TB scanned plus USD 0.02 per GB stored (on-demand). On a typical SMB (50-500 GB hot data, 200-500 queries/day) it lands at USD 200-800/month. In MX and AR, access goes through local resellers with peso billing.
Snowflake is the corporate default. The São Paulo node has been live since 2022. Realistic minimum budget: USD 1,500/month for an SMB, easily ramping to USD 3-5k with undisciplined warehouses. It makes sense when (a) a 3+ person BI team is already in place, (b) data is multi-tenant with complex RBAC, (c) enterprise catalog integration is required.
Databricks is justified only when ML workloads are on the 12-month roadmap. Otherwise it is overkill at USD 2k+/month.
#2. Ingestion
Self-hosted Airbyte OSS — free, 350+ connectors. Downside: operational complexity, unstable connectors in places, ongoing monitoring required. Works if there is a DevOps person on the team.
Fivetran — USD 500-3,000/month for an SMB. Stable but expensive. In LATAM it reads as a luxury line item.
Meltano — open-source orchestration over Singer targets. Cheaper than Fivetran, more flexible, less polished UI.
Custom Python pipelines — for LATAM-specific sources (Mercado Libre API, Rappi B2B, local bank formats, exports from SAT, SUNAT, SII, DIAN). In this sample, 30-50% of real pipelines in LATAM SMBs are custom, because off-the-shelf connectors either do not exist or fail to cover local specificity.
#3. Transformation
dbt is the de facto standard. dbt-core is free. dbt Cloud starts at USD 100/dev/month; for an SMB with 1-3 analysts that totals USD 300-600/month. The alternative is orchestrator + dbt-core. No other serious option exists in 2026. Docs at docs.getdbt.com.
#4. Orchestration
Airflow is the standard but overkill for an SMB. Dagster is more modern with better DX, heavier on day-one setup. Prefect has the lightest start with a less mature ecosystem. The dbt Cloud scheduler handles the first year if everything that runs is dbt.
#5. BI and visualization
Metabase (OSS or Cloud from USD 85/month) and Apache Superset are the most common choices. Looker Studio is free but limited at the modeling layer. Power BI fits when the stack is already Microsoft. Tableau is overkill for an SMB (USD 840/user/year).
#6. Realistic stack for an 80-person SMB
dbt-core + ClickHouse (Hetzner CCX23, USD 200/month) + Airbyte OSS on a separate VM + Metabase OSS. Total run rate: USD 400-600/month plus the time of one part-time data engineer (external contractor at USD 2-4k/month, or an in-house junior). First turnkey implementation: USD 25-45k over 3-4 months.
The alternative "everything in Google Cloud": dbt Cloud Developer + BigQuery + Airbyte Cloud + Looker Studio. Run rate: USD 1,200-2,500/month and zero owned infrastructure.
Country differences: why one stack does not fit all of LATAM
Ignoring the country split is the typical mistake of US consultants who arrive in the region with the "Snowflake + Fivetran + dbt" template. In LATAM that breaks in three countries out of ten.
Argentina. The FX regime (the cepo cambiario, the MEP rate, the official rate) makes any USD billing 40-60% more expensive than the real USD equivalent. A SaaS stack at USD 2,000/month ends up at USD 2,800-3,200/month at the effective exchange rate. On top of that, international transfers carry delays. Bloomberg Línea reports the 2026 growth in formal company count after the deregulation program, but the macro picture with the IMF projections remains fragile. The logical SMB choice: self-hosted ClickHouse on local infrastructure with peso billing. Pulling vouchers from the ARCA (formerly AFIP) API is a separate pipeline. Details in the Odoo Argentina guide.
Chile. The SII spent fifteen years building the region's most mature electronic-document format: DTE (Documento Tributario Electrónico) in XML with a predictable schema. For data engineering it is the ideal source — a single ingest point covers 80% of a small business's operational data. Cloud adoption is the highest in LATAM. Snowflake and BigQuery operate without friction; there is no FX problem. More in Odoo Chile.
Colombia. The DIAN rolled out electronic payroll starting in 2022 — structured data on salaries, contributions, and withholdings now flows in automatically. For an SMB with 30+ employees that turns HR data from a pain into a ready source. Cloud adoption in Bogotá and Medellín sits in second place across LATAM, behind Chile. Context in Odoo Colombia.
Mexico. The SAT (CFDI 4.0) generates volumes that break a naive Postgres + Metabase setup within the third month: a typical SMB issues 50-500k CFDIs per year, plus received CFDIs from vendors, plus payroll CFDIs. Serious analysis needs a DW on day one. Carta Porte 3.1 adds the logistics layer. Mexico is the one country in the region where Snowflake or Databricks makes sense for the average SMB from the start. See Odoo Mexico.
Peru. The SUNAT has been pushing SIRE (Sistema Integrado de Registros Electrónicos) since 2024, partially replacing PLE. The structured registers are direct DW input. Volumes are smaller than in MX — ClickHouse or BigQuery is optimal. Operational details in Odoo Peru.
Brazil (out of scope for this article, but the context matters) is a market 2.5 times larger than all of Spanish-speaking LATAM, with its own Nota Fiscal Eletrônica format, its own vendor ecosystem, and its own dynamics. Entering BR with the rest-of-LATAM template does not work.
When Tier B makes sense — and when it is money down the drain
Triggers where the decision should be "yes":
Scenario 1. 80-person SMB in e-commerce, USD 12M in revenue, sources: Odoo + Shopify + Mercado Libre + Meta Ads + Google Ads + a local 1C for management accounting. Leadership decides marketing mix from manual exports of each system. Decision-to-action delay: nine days. Tier B pays back in 4-6 months through a shorter decision cycle: bad mix and losing campaigns get caught earlier.
Scenario 2. A 220-person manufacturer on SAP Business One, USD 40M revenue. Wants real cost-per-SKU including indirect costs, demand forecasting, production scheduling optimization. Here Tier B is not an alternative — it is a necessary condition. SAP B1 does not compute this natively. First-phase budget: USD 60-120k.
Scenario 3. A 14-location restaurant chain on Odoo + iiko + Rappi + Uber Eats + a local delivery app. The CFO cannot tell in real time whether a specific location is profitable. Three months into Tier B, the answer is yes, and the chain closes two locations that bleed cash.
Cases where Tier B is premature or actively damaging:
Counter-scenario 1. 22-person agency, USD 1.8M revenue. One data source (CRM), one analyst. The real action is to improve reports inside the CRM or build Tier A. Tier B is overkill that drains budget without equivalent return.
Counter-scenario 2. A distributor where data lands in Odoo with a five-day lag, the warehouse runs in Excel in parallel with the system, and stock discrepancies sit above 15%. The first job is fixing source quality. A DW on dirty data does not clean it: it locks the chaos in and makes it expensively visible. Read the Odoo audit angle before considering a DW.
Counter-scenario 3. A company that "wants AI" before it has a working DW and at least one year of clean history. ML on raw ERP data with no modeling layer is venture strategy run on corporate budget. For the why, see Machine Learning for LATAM SMBs.
Five recurring mistakes in LATAM mid-market
#1. Buying Snowflake because "the Fortune 500 does it"
Actual usage: 200 GB hot data and 50 queries a day. Monthly bill: USD 1,800. The equivalent load on self-hosted ClickHouse: USD 250. The difference: USD 18,600/year with no gain in speed or capability.
#2. Building the DW before fixing the sources
An Odoo with duplicated contacts, missing analytic accounts, and monthly manual corrections is the first job. As long as the source is chaos, the DW only multiplies it. One month of Odoo audit and cleanup pays back better over distance than three months of building a DW on top of mess. Operational details in the Odoo audit checklist.
#3. No modeling layer
Analysts write raw SQL straight against raw tables, repeating the same business logic across ten dashboards with micro-differences. Six months in, two executives clash over the definition of revenue on the same platform. The fix: dbt models with tests and documentation from day one.
#4. No lineage, no documentation
Six months in, nobody on the team remembers where the "active customer" metric comes from. The analyst leaves; the knowledge leaves with them. dbt-doc + dbt tests + a lightweight catalog (Notion or Confluence) solves this if it ships in the first iteration, not as the "we will add it later" line item (which never lands).
#5. Hiring a senior in-house data engineer too early
A senior DE in LATAM earns USD 40-80k/year. Filling that calendar with real work in an 80-person SMB during the first six months is not feasible. The logical sequence: external contractor for setup (3-5 months), then a middle DE or analytics engineer for support and growth, and only past the 100+ pipeline mark a senior.
Case: textile distributor in Lima, 84 people, USD 18M in revenue
Situation (anonymized — a composite of three similar cases). The company ran on Odoo Community + a local PLE generator + Shopify + Mercado Libre Peru + Excel for purchases from factories in Gamarra. Monthly close: 14 business days. SKU margin in dispute: internal control showed one figure, the ERP showed another, the warehouse a third. The CEO picked the assortment "by feel."
What was done. Four months with an external team: a data engineer at 0.5 FTE and a BI analyst at 0.3 FTE. Stack: self-hosted ClickHouse (one CCX33 instance on Hetzner Falkenstein, USD 410/month), Airbyte OSS on the same provider, dbt-core with GitHub Actions for CI/CD, Metabase OSS as the front end. Sources: Odoo via Postgres replication, Shopify via Airbyte, Mercado Libre via a custom Python pipeline (no stable Airbyte connector exists), purchases from Excel via a simple importer.
Modeling layer: three levels. Staging (an exact copy of sources with typing), intermediate (joins, deduplication), marts (three: sales, inventory, finance). Final count: 47 dbt models, 89 tests. Documentation: dbt-doc + Notion for business definitions.
Results by the fourth month after go-live: monthly close in four business days (down from 14). Discrepancy across "warehouse / ERP / finance": under 0.8% (down from 6-11%). The team found USD 340k/year of margin leakage: 14 SKUs were selling below cost because of landed cost loaded incorrectly from the supplier. Action: assortment review, USD 180k in margin recovered in the first quarter.
Total project cost: USD 38k one-time plus USD 1,100/month ongoing (hosting + dbt-cloud dev). Payback: 2.7 months after go-live.
"The ROI was not the dashboard. It was the day we saw the SKU we were selling at USD 12 when the real landed cost was USD 14. That single month paid for the whole project year."
What to do now
If you are a CFO or CEO of a 50-500-person LATAM SMB and you recognize at least three of the symptoms from the "when Tier B makes sense" section, the next step is not "hire a data engineer." It is auditing the data sources. How many systems, what quality, which decision cycle is hurting today. That audit takes two weeks and costs roughly USD 3-5k.
To start the audit without commissioning a consultant: data-source audit checklist for LATAM SMBs — 32 points covering Odoo, SAP B1, NetSuite, e-commerce, CRM, and marketing, organized into "quality," "access," and "team competencies." The email arrives on the page.
If you would rather discuss a specific case: book a diagnostic call, 30 minutes, no commitment. No "modern data stack" pitch.
Frequently asked questions
What does a first Tier B implementation actually cost for a LATAM SMB?
The realistic range is USD 25-80k. The floor is self-hosted ClickHouse + dbt + Metabase, one source, two target dashboards, three months. The ceiling is BigQuery or Snowflake + five sources + a full semantic layer + team training, five to six months. Quotes under USD 20k usually mean something got cut — typically tests, documentation, or the modeling layer.
Can you really run production on self-hosted ClickHouse?
Yes, under two conditions: (a) hot-zone volumes up to 5-10 TB, (b) someone on the team who can configure ReplicatedMergeTree and materialized views. In that range ClickHouse is faster than BigQuery and Snowflake. Above 10 TB, or when zero-admin is a requirement, move to a managed option.
When is Snowflake justified over BigQuery or ClickHouse?
Three conditions simultaneously: (a) a 3+ person BI team with warehouse-hygiene discipline, (b) a complex RBAC model with dozens of roles, (c) integration with an enterprise catalog such as Collibra or Alation. Without all three, Snowflake is a 5-10x overpay.
What stack should you pick in Argentina with the FX cap?
Self-hosted ClickHouse or PostgreSQL on a local provider with peso billing, dbt-core (free), Metabase OSS. The managed USD-billed variants raise the run rate by 40-60% at the effective exchange rate.
Do you need an in-house data engineer from day one?
No. For the first 3-5 months use an external contractor or agency for setup. After that, hire a middle DE or an analytics engineer for support and growth. A senior DE is justified only at 80+ active pipelines or complex streaming workloads.
How soon do the first usable dashboards appear?
Realistic timeline: models in week 4-6, first validated dashboards in week 8-10, team trust and habitual use between week 12 and 16. Anyone promising "production-ready in four weeks" is selling a slide deck, not a solution.
How is Tier B different from Power BI + Excel?
Power BI and Excel are a presentation layer, not storage. Power BI on top of Tier B is a perfectly valid architecture. The trouble starts when teams try to use Power BI as a "data warehouse" via Power Query: at SMB volumes it breaks at the two-year retention mark and when a second source arrives.
Does it make sense to start with Tier B if Tier A is still missing?
Almost never. Tier B demands source discipline that Tier A forces a team to develop first. Skipping Tier A usually leaves the DW team cleaning data for the entire first year instead of modeling. If ERP data is already clean, the skip is possible — but that condition gets validated through audit, not intuition.
What if the team does not have an analyst who knows SQL?
Then Tier B returns nothing in the first year. Before investing in infrastructure, hire an analytics engineer or BI analyst who can use the models. Without that role, the DW becomes a museum: impeccable structure that nobody consults.
Related material
This article is part of the Data Engineering pillar in the Sergéi Filatov / Hacker Sergio line. For the country angle: Odoo Peru, Odoo Chile, Odoo Mexico, Odoo Colombia, Odoo Argentina. For the bridge between Odoo and analytics, Odoo + Analytics. For specific stacks, ClickHouse, BigQuery, Databricks. For adjacent use cases, Business Intelligence, Machine Learning, Computer Vision.
Author: Sergéi Filatov (Hacker Sergio), Forbes 30 Under 30 LATAM, Lima. Architect of data engineering and Odoo implementations for SMBs and enterprise across ten countries in the region. Profile and portfolio.
Last updated: May 27, 2026.