FlowFuse
Database Offerings
Alongside our Broker offering, we'd be looking to offer a database too, or at least integrate and provide enhanced UX around existing DBs.
Where possible, especially as a first iteration, we'll be looking at partner technologies/offerings here.
### Tasks
- [ ] Historian/Timeseries Database Offering
- [ ] Structure/SQL Database Offering
Requested by:
-https://app-eu1.hubspot.com/contacts/26586079/record/0-1/209119058119
@ZJvandeWeg agreed to explore partnership opportunities here to supplement a FF database "offering"
Not a hard requirement for MVP if it helps ship quicker to FFC - but we should ensure what we do has a route to being self-hosted. Prioritise k8s > docker > localfs.
Looking at what metering options are available for PostgreSQL.
It looks like we can determine a given database's size easily enough with select pg_database_size('databaseName')
Not sure what else we can easily measure with standard PostgeSQL
@hardillb Some things that would be nice to track as we use this MVP to determine a model for a more complete feature:
- Compute used
- Memory used
- Reads, writes, queries
- Data ingested
- Database size
@ZJvandeWeg I would like to offer the beta MVP of this on the Pro tier as well as Enterprise. As we discussed last week, we will revisit the pricing model for this based on what we learn about usage in the initial period following the release. Can we include the feature for the Pro tier?
What are they trying to achieve: I want to connect, extract the data from the shopfloor, and integrate it with whatever the use case demands. I want to optimize things that can have a $100k/year impact.
@gstout52 No, let's start with Enterprise. That part you wrote describes well why it should be Enterprise.
The plan I had put forward is that the beta goes out for free to everyone, then we scale it back to a specific tier when we officially take it out of beta. It gets us usage data, gives us feedback around UX, and helps us gauge popularity far better.
Having this only on Enterprise gives us no data about usage, no visibility to trial users, etc. Enterprise customers are not, regularly, working on greenfield projects. They're not going to migrate existing projects over to our database, especially if it's branded as a "beta" feature. Shipping this to Enterprise only is a waste.
The better approach here is to throttle with usage limits by tier. It offers an incentive for growth, customers wanting to use this at scale still have to pay for it, but it opens up an opportunities for mass adoption as we could be offering a full MING-esque stack as a "starter" deal (throttled in appropriate places accordingly). Self-serve MRR isn't going to grow if all we are offering for self-serve is cloud-hosted Node-RED.
Removing this just leaves us with the Node-RED w/AI angle for Starter, which could still work, but doesn't align to the company vision of "FlowFuse will empower 1 billion people to fuse the digital realm and physical reality through building bespoke workflows, applications, and integrations, unleashing their creativity so that they can effortlessly leverage their own skills and expertise."
If we want to go large on our market we have to be thinking outside of Manufacturing/(current) ICP base, and considering more general purpose application building, where Node-RED becomes an easy vehicle by which to write your database, with server-side logic, with a UI/Dashboard, and with the option of realtime data via MQTT too
This won't be available for free or included in our Starter tier (nor Team). We're being thoughtful about not taking away something that's free/cheap or open-source, which is why we're planning to start this at the Enterprise level.
- It avoids the scenario of removing a feature that users have come to rely on
- It allows us to better understand the long-term impact and usage patterns at scale with our Enterprise customers first
Starting at the Enterprise tier will give us production metrics into how this feature performs in production environments and help us refine the offering before considering broader availability.
The mission of reaching billions of people won't happen overnight, and as such we can delay the roll out to other tiers and not require more work and metrics first.