A database connection would operate either in IO (the generic "i am now talking to an unreliable outside world") monad, or some more specific monad.

In this case you can think of a monad a bit like a computational context. If one is not present, you simply cannot[^1] instruct a Haskell program to perform those operations in a type safe way even if you give it a valid database connection identifier.

[1] Well, you can, but if you do you're explicitly taking away all the safeguards that Haskell introduces, and it would never pass code review.

In Haskell, you often build pure transformations, and then lift them into an effectful context. If I have a function `String -> [String]`, say to parse a line of CSV into its elements, I can lift that to `IO String -> IO [String]` using the IO monad's `fmap`. And then I can compose it with something hypothetical like `readLine :: File -> IO String`, which actually reads the line.

The core logic of a program often doesn't need to care deeply about state or system resources. Pure functional programming is about writing as much as you can in this "functional core", and then lifting the assembled pieces of pipeline into the "imperative shell" (such as the IO monad).

As a concrete example, there's a nice function in Haskell's standard library called `interact :: (String -> String) -> IO ()`: https://hackage.haskell.org/package/base-4.14.1.0/docs/Prelu...

Its argument is a function of type `String -> String` and it returns an `IO ()`, i.e. an i/o action with a trivial result. That action will call the given function on contents of stdin, and writes its result to stdout. Or, equivalently, we can think of `interact f` as transforming a pure string-processing function `f` into a stdio CLI.

Note that laziness (specifically "lazy IO") causes stdin to be read 'on demand', giving us a streaming computation without any extra work. Here's an example implementation of 'wc':

    module Main where
    import System.IO

    main :: IO ()
    main = interact count

    count :: String -> String
    count input = show (length (unwords input))

Bonus: if we want to show off, we could implement 'count' using function composition like this:

    count = show . length . unwords

pedantically, talking to the database will involve sending a request or some kind of IPC, all of which are usually considered side effects.

[handwavy analogy alert]

people often call it "side-effects" as a shorthand. in reality an expression being of type `IO Foo` mostly just tells the compiler that order of execution matters (which isn't the case with pure functions):

  do print "a"
     print "b"
 
  -- obviously not the same as
  
  do print "b"
     print "a"

and also that it can't eliminate common expressions:

  do a <- readBytes file 100
     b <- readBytes file 100
     doStuff a b

  -- obviously not the same as

  do x <- readBytes file 100
     doStuff x x

it's a way of enforcing ordering in a lazy language where evaluation order isn't really defined.