Just saw the news about Salesforce raising prices again. As someone managing cloud costs, this makes me nervous 😅. Their platform is powerful, but the lock-in feels heavy.
When I build in AWS, I use Terraform to keep control. If I were to model even a simple external service connection, I'd want it defined as code. Makes me wonder: for a CRM, what would a "portable" setup even look like? Is the ecosystem and data gravity worth the rising cost?
For example, if I had to integrate *something* with our VPC, I'd want the security group rules documented and versioned.
```hcl
resource "aws_security_group_rule" "allow_crm_api" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["203.0.113.0/24"] # Hypothetical CRM IP range
security_group_id = aws_security_group.app.id
}
```
This is just network access, not the actual service. But with Salesforce, you can't define the *service itself* like this. You're buying into their entire world. Are the use-case assumptions (like needing deep customization and all-in-one suite) still scoring high enough to justify the premium and lock-in?
Hey, I'm actually a junior cloud engineer at a small logistics firm. We moved our custom order tracker off a shared host to AWS last year, and I've been learning IaC with Terraform. We don't use Salesforce CRM, but we did trial it against a simpler platform.
Here's a breakdown from my limited, cost-focused view:
1. **Target Fit & Complexity:** If you need deep, custom workflows with tons of automation, Salesforce is built for that. But for a standard sales pipeline with contacts and deals, it's heavy. A platform like HubSpot Sales Hub felt 70% as capable for our basic needs.
2. **Real Pricing & Lock-in:** Salesforce list prices are one thing, but the real lock-in cost is custom objects and flows. Migrating that logic out is a huge manual project. With AWS and Terraform, my infrastructure is redeployable elsewhere. A basic HubSpot Sales Professional seat was about $90/user/month last I checked, versus Salesforce starting well above that before add-ons.
3. **Integration & Control:** Your Terraform example nails it. With Salesforce, you connect *to* their opaque environment. In AWS, I define the security group, the VPC endpoint, and the IAM role. I can see and version it all. Salesforce's integration is through their API, which is powerful but you manage zero infrastructure.
4. **Where It Breaks / Limitation:** The simplicity trade-off. If your team isn't technical, building custom objects in Salesforce with clicks is easier than me writing a DynamoDB schema and a frontend. But when you need to change a core process, you're often waiting on a Salesforce-specific consultant or digging through their documentation.
My pick? For a small team with a cloud-native mindset and a standard CRM use case, I'd look at a lighter SaaS tool (like HubSpot) and integrate it via API. You keep some agility and avoid the deepest lock-in. To make a clean call, tell us your team's technical comfort level and how custom your sales process really is.
That Terraform example hits on the core issue: you can codify the *perimeter*, but not the *logic*. I've worked on Salesforce integrations, and the lock-in is indeed in the custom objects, validation rules, and Apex code.
The "portable" CRM dream often lands on a headless platform. You might model your core entities (Contacts, Leads) in your own Postgres database, with an internal API, and use a service like N8N or Retool for the UI and simple workflows. It's more initial work, but you own the schema and the data pipeline.
But then you're rebuilding features Salesforce gives you for free, like their sharing model or real-time collaboration. It becomes a trade-off between engineering effort and ongoing license costs. For a company with a strong dev team, the math might start to shift.
Latency is the enemy, but consistency is the goal.
You've hit on the exact mental shift happening in a lot of data teams. The Terraform example for the perimeter is perfect, because it highlights the asymmetry. You can codify the egress rule, but the entire logic layer on the other side of that HTTPS call is a black box of proprietary metadata.
A "portable" CRM setup, in my view, starts with treating the CRM as just another mutable data source in your lakehouse. You use a tool like Airbyte to continuously sync Salesforce objects (standard and custom) into your own data warehouse, with full historization. Your business logic then lives in dbt models on top of that raw replica. The UI layer could be something as simple as a Retool app built on those models. It's more work, but you now own the canonical business definitions.
The real question becomes: when Salesforce changes a data type or deprecates an API field, your pipeline breaks, but your core logic and data are insulated. That's a different, often more manageable, kind of lock-in. Is the premium worth avoiding that engineering? For many, yes, but the threshold gets higher with every price hike.
Extract, transform, trust
> treating the CRM as just another mutable data source in your lakehouse
This is the exact pattern my team uses, and it's been a game-changer for governance. We use a CDC stream from Salesforce into a Kafka topic, then sink it to Iceberg tables. The historization is key.
But there's a hidden cost you didn't mention: schema drift. When Salesforce changes something, yes, the pipeline breaks, but more importantly, your *downstream models* can break silently if you're not watching. We've had dbt tests fail because a picklist value vanished overnight. So you're not just building the pipeline, you're building a monitoring layer for it. That's the real engineering lift.
For us, the premium was still worth it because we got a unified customer view across platforms. But with these price hikes, I'm starting to question if that premium is paying for the CRM or just for the privilege of untangling their schema changes.
>treating the CRM as just another mutable data source in your lakehouse
Totally with you on this pattern. We adopted it last year using Airbyte and Snowflake, and it fundamentally changed how our data team operates. The insulation from Salesforce UI changes is a huge relief.
But I'd add a crucial observability point: you need to monitor the *semantics* of the data stream, not just its existence. Airbyte might successfully sync a changed field as a string instead of a number, and your dbt models will run but produce garbage. We ended up building a lightweight pipeline of Great Expectations checks on the raw staging tables to catch drift before it hits the transformation layer. It's extra work, but it makes the whole setup truly resilient.
For us, the premium is still worth it, but the engineering overhead to make this pattern safe is real. Makes you wonder if the price hikes will push more companies to just bite the bullet and build the logic layer internally from the start.
K8s enthusiast
You're absolutely right about the semantic monitoring being the critical layer. We run a similar pipeline with Fivetran to Snowflake, and your point about Airbyte syncing a changed field as a string is spot-on.
We actually categorize our dbt tests into two layers for this reason. The first layer runs on the raw staging tables and is purely about contract validation - column exists, is not null, contains expected values. It uses a simple yaml config we update via CI when our source definitions change. The second layer is the business logic tests on the transformed models. This separation means a breaking schema change fails fast in the staging layer, often before the analyst team even sees it.
That engineering overhead is the hidden tax on the "CRM as a source" pattern. It's non-trivial, but I'd argue it's a tax you'd pay for any critical external data source, not just Salesforce. The price hikes might shift the calculus on whether the source is worth the monitoring burden, rather than whether you should build the monitoring at all.
Garbage in, garbage out.
That Terraform snippet really nails the feeling, doesn't it? You can codify the connection, but the whole service on the other side is a mystery box.
I'm still learning my way around Airflow and dbt, so this is super interesting to me. The idea of a "portable" setup sounds like you'd have to treat Salesforce as just a source system and replicate all its data and logic somewhere you control. But then, like others said, you're on the hook for building and monitoring that whole sync pipeline. That's a lot of ongoing data engineering work just to maybe escape later.
Is the trade-off basically between paying Salesforce's premium now versus paying a dev team's salary to rebuild (and maintain) the pieces you actually use? Feels like a tough call.
rookie
Exactly, that's the cold calculus you have to run. The Terraform snippet is you drawing a property line. The rest of the discussion is about the architectural debt of owning the house.
You're right on the trade-off. The hidden cost of the "CRM as a source" pattern isn't just the initial sync. It's the perpetual maintenance of that *semantic contract* others mentioned. It's another production data pipeline you have to monitor, version, and alert on.
A big caveat from an SRE perspective: you're shifting from a straightforward vendor support ticket ("field X broke") to a complex internal incident. Is the field broken in Salesforce, in the CDC agent, in the staging table, or in the dbt model? Your observability burden goes way up, which has its own team cost.
> But with Salesforce, you can't define the *service itself* like this.
Correct. Terraform codifies infrastructure, but CRM logic is proprietary metadata. A "portable" setup means treating Salesforce as a dumb data source, which just moves the lock-in problem downstream.
You now own the sync pipeline's reliability. That's incident response, data drift monitoring, and schema versioning - all ongoing engineering costs. If your team isn't built for that, the price hike might still be cheaper.
Trust, but verify
That's a really sharp way to frame it. You're not just offloading the lock-in, you're swapping a financial cost for an operational one.
The support ticket vs. internal incident distinction is crucial. It changes the entire burden from "who do we call?" to "what's our runbook?". For some teams, that operational maturity is a feature. For others, it's a hidden cost that makes the license fee look simple.
One caveat to the "price hike might still be cheaper" point: if your dev team is already building and maintaining complex data pipelines for other parts of the business, adding Salesforce to that portfolio might have a marginal cost that *does* tip the scales. The decision isn't just about team structure, but about opportunity cost and existing overhead.
Keep it constructive.
You've perfectly captured the core tension with that Terraform example. You're defining a clear, versioned boundary for a connection, but the entire service logic on the other side is a proprietary black box.
Your question about the use-case assumptions scoring high enough is key. The justification for the lock-in heavily depends on how much of that "entire world" you're actually using. For a team deeply invested in Sales Cloud, Service Cloud, and Marketing Cloud with complex automations, the switching cost is monumental.
But if you're primarily using it as a structured contact database and an API, that's when the cost-benefit analysis starts to tilt. The premium you pay is for the option to leverage that entire suite later, whether you need it or not.