Presented by
Happy October 12th, Industry 4.0!
Today's a federal holiday, which means the banks are closed, the mail isn't coming, and a good number of you are at the plant anyway. The line doesn't read the federal calendar.
Meanwhile, the industry spent last week doing what it does when the rest of us aren't looking: writing a very large check. Schneider Electric announced it's buying PTC for $22.6 billion, and if you run Creo, Windchill, or anything that touches a bill of materials, you probably have questions. We've got a few answers, and a short list of questions to take to your vendor rep.
Also on the docket: a team that fixed its slow search by using the database it already had, an AI model that just got a lot cheaper (and where it actually belongs on your floor), and a way to define AI agents in a config file you can version like any other piece of infrastructure.
Grab your coffee. Here's what caught our attention:
Schneider Electric Is Buying PTC for $22.6 Billion. Here Are the Questions to Ask Your Vendor.
Schneider Electric just made the largest acquisition in its history, and it's a software company that sits right in the middle of how products get designed and built.
The details:
- Announced Monday, October 5: $205 per share in cash, a 42.3% premium over PTC's previous closing price of $144.03
- Roughly $22.6 billion in equity value, or about $23.7 billion including debt
- Expected to close by Q3 2027, pending regulatory approval and a PTC shareholder vote. PTC's board has approved it
- Schneider projects about €250 million in annual cost savings by year three
- It's bigger than Schneider's 2023 AVEVA purchase (about £9.5 billion), and it follows Schneider's June agreement to buy industrial AI company Cognite for $3.1 billion, which hasn't closed yet
Why it matters: Schneider's pitch is a "digital thread": connect product design (PTC's CAD and PLM tools) to plant operations and energy systems (Schneider and AVEVA), with a shared data layer underneath. Whether that's vision or marketing is something only the next few years will answer.
One thing worth clearing up, because it's been the first question in our community: Kepware and ThingWorx aren't part of this deal. PTC sold both to TPG in a deal that closed on March 16, 2026. If you're a Kepware customer, this announcement doesn't change who owns your connectivity layer.
If you run PTC's design and PLM tools, that's a different story. PTC has more than 30,000 customers, and the coverage we read doesn't include any specific commitments on pricing, support, or roadmap. That's not unusual this early. It does mean the commitments are yours to ask for.
Real-world scenario: Imagine your engineering manager walking into the Monday meeting: "Our change-order process runs through Windchill, and it feeds the MES. Schneider now owns Windchill. What happens to that integration?" Right now, nobody outside the two companies can answer that. You have until closing to get answers in writing.
The bottom line: Consolidation isn't new, but the stack you've been assembling from separate vendors is getting shorter. Know which of your integrations would hurt most if a roadmap changed, and start the conversation before you need the answer.
Before You Add Another Search Engine, Check the Database You Already Run
A software team replaced its search engine with plain PostgreSQL, and the slowest queries got up to 8.6 times faster.
The details:
- Cortex, a developer-tools company, had built search on Lucene. Indexes were rebuilt on a schedule, stored, then loaded into application memory. As customers grew, some index objects reached about 1 GiB, causing out-of-memory errors and slow first queries
- The fix was to push search into Postgres itself using full-text search (a
tsvectorcolumn with a GIN index), a custom query parser, and weighted ranking - Updates now flow in through change data capture (CDC), which listens for database changes and applies them within seconds instead of waiting for a scheduled rebuild
- Public API p95 latency (the time within which 95% of requests finish) dropped from 13.3 seconds to 1.54 seconds, and total memory use fell by roughly 40%
- Most edits now become searchable within a couple of seconds. Before, it took at least five minutes
Why it matters: Translation: you may already own the tool you're about to buy. Plants are full of searchable text: work orders, maintenance logs, SOPs, parts catalogs, downtime comments. Most of it lives in a relational database someone already backs up and patches. Adding a separate search system means one more thing to secure, monitor, and keep alive on a network where every new system is a risk assessment.
Cortex had a version of that constraint too. They needed to run anywhere with as little as a Postgres database, so they stuck with features that ship with standard Postgres.
Real-world scenario: A technician types "gearbox" into the maintenance system at 2 a.m. and waits. Or worse, gets forty results sorted by date, none of them the one that matters. Ranking matters: Cortex put exact matches first, then partial matches, then the fuzzier "close enough" results.
How it works, in steps:
- Store a search-ready copy of each record's text with weights, so a match in a part name counts more than a match buried in a description
- Add a GIN index so Postgres can look up words without scanning every row
- Rank in tiers so an exact match always beats a partial one
- Keep it fresh by listening for changes instead of rebuilding on a timer
- Keep a nightly full rebuild as a safety net
Pitfalls to avoid:
- Cortex skipped word-stemming on purpose, because names and identifiers shouldn't be folded together. That matters for part numbers
- Don't let one big change (renaming a group with thousands of members) stampede your database in real time
Keep it honest: This is Cortex's own data on a software catalog, not a plant historian, and your workloads will differ. But the principle holds: measure before you add a system.
The bottom line: Before you buy a new tool, find out how far the database you already run can take you.
Claude Haiku 5.5: A Cheaper AI Model, and Where It Belongs on the Floor
Anthropic just released a small AI model priced for the kind of boring, repetitive work that plants have plenty of. (Disclosure: it's the vendor's own announcement, so the numbers below are the vendor's numbers.)
The details:
- Anthropic says Haiku 5.5 costs around 75% less to run than Haiku 4.5 on average. Per-token pricing is $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100,000 tokens
- It's aimed at summaries, classification, database queries, and subagent work, plus speed-sensitive jobs like live customer support
- It's the first Haiku with an adjustable effort setting, so you choose whether to optimize for cost or accuracy
- It's available on Anthropic's platform, AWS, Google Cloud, and Azure
- Anthropic also halved Sonnet 5.5's cache-read price, which it says cuts that model's cost on most agentic work by about 20%
Why it matters: Cheap changes what's worth automating. A task that cost too much to run on every record last year might be a rounding error now. But Anthropic is clear that this isn't the model for hard problems. Its own benchmarks show Haiku 5.5 scoring 39.2% on Terminal-Bench 4.0, a command-line coding test, against 70.6% for Sonnet 5.5. It's built for narrow, well-defined jobs.
Where to start:
- Pick one narrow task with a clear right answer, like classifying downtime reasons
- Hand-label about 100 examples and test the model against them
- Track the disagreement rate, and keep a human on anything that touches safety or quality
- One note for security teams: Anthropic says Haiku 5.5's cyber safeguards still block penetration testing and similar techniques, though defensive work is permitted
The bottom line: When a model costs this little, the question changes from "can we afford to run it?" to "can we prove it's right?"
Sponsor Message
Keep your history. Keep your Postgres.
Every PLC tag, sensor, and machine state on your floor writes a new reading every few seconds. Multiply that by a year of history and every IIoT team lands on the same two questions: where does all of it live, and who has to maintain it?
Tiger Data keeps the answer simple with Tiger Cloud: it's their fully managed PostgreSQL solution, built for time-series, so your team keeps the SQL it already knows.
- Built for time-series data: Tables partition by time automatically, and older data converts from fast row storage to columnar. Compression can reach up to 95%, with automatic tiering to low-cost object storage for long retention
- Built to stay up: Multi-AZ clusters with automatic failover, point-in-time recovery, and cross-region backups
- Built for your security review: SOC 2, HIPAA, and GDPR compliance, always-on encryption, SSO, role-based access control, and audit logging
- Built for scale: Tiger Data has proven that a single Tiger Cloud service can handle 3 trillion metrics a day and 3 petabytes of data
Try it on your own data: New Tiger Cloud accounts get $1,000 in credit, valid for 30 days, with no credit card required. New accounts only.
Create an account and get $1,000 in credit ->
Docker Agent: Define an AI Agent in a YAML File, Package It Like a Container
Docker now lets you describe an AI agent the same way you'd describe a container: in a config file you can version, review, and share.
The details:
- Docker Agent is a Docker CLI plugin (
docker agent), pre-installed in recent Docker Desktop versions (4.63 and up, per the project's README) - Agents are defined in YAML: the model, the instructions, and the tools it can use, including any MCP server (Model Context Protocol, the standard way to connect AI to tools and data)
- You can build teams of agents that hand work to each other
- It works with multiple model providers, including OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, and xAI, plus local models through Docker Model Runner
- Finished agents can be pushed to and pulled from any OCI registry, the same kind of registry your container images already use
Why it matters: Here's the thing about "AI agents" in a plant: the scary part isn't the AI, it's the access. A config file makes that access visible. You can read exactly which tools an agent can call, review a change before it ships, and roll it back, the same discipline you'd expect for PLC code or a recipe change. Support for local models also opens the door to running agents on a network that can't call out to the internet.
Getting started:
- Install the plugin (it's included in recent Docker Desktop), then set a model API key or use a local model
- Run
docker agent newto generate a starter config, or write your own YAML - Start it with
docker agent run agent.yaml
Pitfalls to avoid:
- Start with read-only tools. An agent that can write is a different risk conversation
- The project says it collects anonymous usage data, so check the telemetry settings before you put it anywhere near an OT network
- Keep API keys off shared machines. We haven't run it ourselves, so test it in a sandbox first
The bottom line: An agent you can read in a diff is an agent you can govern.
From the Floor: A Week in the Community
From October 2 to October 12, the 4.0 Solutions / Industry 4.0 Discord was dominated by a single story: Schneider Electric buying PTC. Message volume was moderate, but the discussion was technical and thoughtful, and the week also turned up a classic UNS naming headache and a solid cloud-versus-on-prem debate.
Is the Schneider-PTC deal good for the industry? Across #📰-industry-news, #💬-general, and plenty of side chats from October 5 to 8, members debated whether consolidation helps or whether there's too much roll-up. Several pointed to the pattern: Schneider's Cognite agreement in June, now PTC, and a read that it's all aimed at competing with Siemens on design and lifecycle software. du5tins brought the integrator's view, worried about what a wave of consolidation means for industrial connectivity tools like Kepserver over the long run. (As we covered above, Kepware moved to TPG back in March, so it isn't part of this deal.) The verdict on whether this helps or hurts end users and SIs is still open.
Cloud vs. on-prem for manufacturing: In #cloud on October 8, members worked through the CAPEX versus OPEX trade-offs and the industry's push toward cloud-only MES. The sharpest points were about what's missing: credible on-prem redundancy options, and how some vendors price per connection. It's evergreen, and people clearly care.
Design for manufacturability: In #💬-general on October 4 and 5, new member chabuduo_precision introduced OpusFab, a prototype-to-production platform, and got a genuinely useful back-and-forth on DFM and DFA concepts with monikerov and nickn5549, who's building something similar for PCBA.
50,000 MQTT topics and a Grafana problem: In #unified-namespace (October 4 and 5), workingnetworks described a very practical headache: about 50,000 MQTT topics, many too long to read in Grafana. tomasz_leanit offered abbreviation dictionaries and flattening strategies. No final answer yet, so if you've solved this at scale, jump in.
Also worth a look: Has anyone dug into Neuron Industries' technology? The question is still waiting for someone with hands-on experience.
Not in the room yet? Come hang out in the Discord -> That's where the real work gets argued out.
Byte-Sized Brilliance
The $22.6 Billion Software Company Is Older Than the Web
PTC was founded in 1985 by Samuel Geisberg and Mike Payne. Its flagship product, Pro/ENGINEER, reached the market in 1988 and is widely credited as the first parametric modeling software. That means the first CAD tool built around a simple idea: dimensions are variables. Change one number, and the entire model rebuilds itself around it.
That's the part we love. More than four decades before anyone said "digital thread," the founding trick was making a change in one place ripple correctly through everything connected to it. Schneider is now paying $22.6 billion, the largest deal in its history, to own a company built on that idea.
It's also the quiet lesson in this week's other stories. Whether it's a CAD model, a search index, or your plant's data layer, the hard part isn't storing things. It's making sure that when something changes, everything that depends on it finds out. That's true for parts, and it's true for your tags.
Source: Wikipedia, "PTC Inc."
Responses