Question to use m36

[秋葉杏介]

My name is Akiba.

I strongly sympathize with the philosophy of Project M36, and over the past few days I have been exploring whether it could be integrated into software that I currently operate in production at work.

With the assumption that I am not very familiar with Haskell itself, I have a few questions.

1. How should migrations be handled?

   I would be very happy if something like the following were possible:

   https://supabase.com/docs/guides/local-development/declarative-database-schemas

   At the moment, when changing the database schema based on the data type definitions used in Haskell, it seems necessary to manually create migration files so that they match the types.

   While developing, I felt somewhat uneasy because this breaks the idea of a single source of truth (SSOT).

   Are there any practical examples or recommended approaches for handling this?

2. Concerns when using M36 in a production product

   Because I am not very familiar with Haskell, I feel that I may not fully understand—partly related to question 1—what M36 cannot do or what its limitations are.

   This may be an impolite question, but I would really appreciate it if you could share some insights.

I have not been able to find any other database engine with such a small impedance mismatch and such strong expressive power in its type system as M36.

Thank you very much for creating this product.

[A.M.]

On 12/26/25 19:54, 秋葉杏介 wrote:
> My name is Akiba.
>
> I strongly sympathize with the philosophy of Project M36, and over the
> past few days I have been exploring whether it could be integrated into
> software that I currently operate in production at work.

Hi Akiba!

Thanks for your email!

> With the assumption that I am not very familiar with Haskell itself, I
> have a few questions.
>

> 1.
>
> *How should migrations be handled?***

>
> I would be very happy if something like the following were possible:
>
> https://supabase.com/docs/guides/local-development/declarative-
> database-schemas
>
> At the moment, when changing the database schema based on the data
> type definitions used in Haskell, it seems necessary to manually
> create migration files so that they match the types.
>
> While developing, I felt somewhat uneasy because this breaks the
> idea of a single source of truth (SSOT).
>
> Are there any practical examples or recommended approaches for
> handling this?

Project:M36 has some novel features which can be used to alleviate the
pain of migrations:

1. Migrations are low-risk.

Schema migrations can be tested on a separate branch, tested, and merged
back into your main branch, just like code.

2. Registered queries and schema hashing ensure clients are in sync.

https://github.com/agentm/project-m36/blob/master/docs/Handling_DDL_Changes.markdown

In general, automatic schema migrations fall flat because:

* they cannot derive business-logic-based migrations
* they cannot detect table/view renames
* SQL databases don't track schema change history for comparison purposes
* they rely on SQL NULL to backfill data which is rarely what the
developer actually wants

Take a look at all the limitations at the bottom of the supabase page
linked above. Automatic schema migrations are really only good for
use-cases where the schema is simple and devoid of business logic
whereas Project:M36 promotes business logic in the database.

Schema migrations are an active area of research, so Project:M36 will
definitely aim to be at the state-of-the-art in this field.

>
> 2.
>
> *Concerns when using M36 in a production product***

>
> Because I am not very familiar with Haskell, I feel that I may not
> fully understand—partly related to question 1—what M36 cannot do or
> what its limitations are.
>
> This may be an impolite question, but I would really appreciate it
> if you could share some insights.

It would definitely be an advantage to know and use Haskell with
Project:M36. The benefits have to do with eliminating the common SQL
type impedance mismatch whereby types in Python, for example, are not
the exact same types in SQL. Server-side functions are also implemented
in Haskell.

However, it's possible to use Project:M36 without Haskell knowledge
using the websocket server and a client language of your choice,
optionally leveraging TutorialD or the SQLegacy language. Just know that
the full advantages of Project:M36 are unlocked with Haskell.

>
> I have not been able to find any other database engine with such a small
> impedance mismatch and such strong expressive power in its type system
> as M36.
>
> Thank you very much for creating this product.

Thanks for your interest! Which features of Project:M36 do you find most
interesting?

Cheers,
M